System design for real traffic, not whiteboard traffic

Whiteboard system design and production system design share vocabulary and almost nothing else. In interviews you draw boxes until the diagram looks impressive. In production you find the one component that breaks first and fix exactly that.

Find the first bottleneck

Every system has one. For a typical CRUD-heavy platform like the ones I work on, it is almost never the web tier — it is the database, and specifically a handful of queries:

• ✦The unindexed filter that was fine with 10k rows and is not fine with 10M
• ✦The N+1 that an ORM hid until traffic made it visible
• ✦The report query that locks a table exactly at business hours

Measure before you architect. One EXPLAIN ANALYZE is worth ten diagrams.

Cache with a story, not a shrug

Redis in front of everything is not a strategy. Each cached value needs three answers: who invalidates it, how stale can it be, and what happens on a miss stampede. On a loyalty platform, point balances tolerate seconds of staleness; a POS receipt total tolerates none. Same system, different rules per data class.

Queues buy you honesty

RabbitMQ earns its place the day you admit some work does not belong in the request cycle — receipts, exports, emails, sync jobs. The pattern that keeps it sane: the API writes a fact to the database, publishes an event, and answers fast. Workers own the slow part and can fail, retry and backfill without a user watching a spinner.

Scale the boring way

Vertical first, then read replicas, then sharding — each step only when the previous one runs out. Most products die from complexity added too early, not from load arriving too late. The best system design skill is knowing which problems you are not going to solve this quarter.