Decision tables
Six decisions come up in almost every round. Each has a default you can defend, a pressure that flips it, and one number that tells you which side of the line you are on. Here they are, verdict first, with the arithmetic under each.
Should I pick SQL or NoSQL in a system design interview?
Start relational unless something pushes you off it, and say what would. One relational primary takes about five thousand synced writes a second and a node holds about ten terabytes; reads grow with replicas and caches, so they rarely decide it. Move to a key-value or wide-column store when the writes or the data pass one primary and every query arrives with one key. Say the number that put you there.
When is eventual consistency acceptable?
When a read that is a moment stale costs nothing a user can notice or lose: like counts, feeds, presence. Money, stock and anything that must be unique (a seat, a username) need strong consistency. Across regions a strong write waits for a round trip across an ocean, about 150 ms, so the usual design is strong inside a region, asynchronous between regions, and read-your-writes for the user who wrote.
Fan-out on write or fan-out on read for a news feed?
On write for almost every author, because a feed is loaded far more often than it is posted to, and on read for the few authors with huge followings. Copying one post into twenty million inboxes at 2,000 writes a second takes 10,000 seconds, far past a five-second freshness target. The hybrid pushes for everyone under the star line and merges the stars in at read time.
Which caching strategy should I use: cache-aside, write-through or write-behind?
Cache-aside by default: read the cache, fill it from the store on a miss, and delete the entry when you write. Write-through when a read right after a write must find the new value in the cache. Write-behind only for writes you can afford to lose, such as like counts, because the cache holds them until the next flush and a dead cache node loses whatever it held.
When should I use a message queue instead of a direct call?
When the caller does not need the result to answer. Every synchronous call adds its latency and its downtime to the request: five services in a row at three nines each are up 99.5 percent together, 215.6 minutes down a month against 43.2 for one. Keep the step whose answer the user waits for synchronous, and put the rest behind a queue with idempotent consumers.