44 scenarios — canonical answer and when the opposite is right.
Sorted by interview frequency
You're building a banking ledger with multi-row transactions and complex reports across accounts, transactions, and customers.
A user uploads a video that must be transcoded into 5 resolutions before being playable.
Small team (8 engineers) building a new B2B SaaS product.
Read-heavy workload where staleness for a few seconds is tolerable.
Multiple users may edit the same document, but concurrent edits are rare.
You need to fan out user events to ~10 downstream services and let each independently replay the last 7 days for backfill.
You're designing internal service-to-service APIs (Application Programming Interfaces) across polyglot backends with strict latency service level agreements (SLAs) and schema evolution.
A collaborative editor needs sub-100ms updates across users.
Single Postgres instance approaching CPU saturation as traffic grows.
Designing a fleet of API (Application Programming Interface) servers that need to scale horizontally based on traffic.
Sharding 100GB of session data across 10 cache nodes, with occasional node additions/removals.
Mobile clients on flaky networks need to fetch a screen's worth of nested, related data in one round trip.
Analytics dashboard scanning aggregations over billions of rows but only 3-4 columns at a time.
Write-heavy app deployed to two regions for low-latency writes in both.
An order checkout flow spans payment, inventory, and shipping microservices.
You need a cache that also supports rate-limit counters, sorted sets for leaderboards, and pub/sub for notifications.
Public blog/marketing site that needs SEO and fast first-paint on mobile.
Real-time multiplayer game where player positions update 60×/sec.
User requests account deletion in a system that powers downstream analytics.
Mid-size startup with shared libraries across 12 services, frequent cross-cutting changes.
A hot counter is hit by 64 threads thousands of times per second. You need correctness without crushing throughput.
A service makes ~5 downstream HTTP (Hypertext Transfer Protocol) calls per request, 80% of request time is waiting on I/O, and you expect 50k concurrent connections.
You're locking a 1M-entry in-memory map. One big lock is simple but throughput is poor under writes.
Multiple users edit the same record but conflicts are rare. You're choosing the concurrency-control model.
You're building a stateful service with many internal components mutating shared state. You want to keep it correct as it grows.
Your service issues many DB and HTTP (Hypertext Transfer Protocol) calls per request. You're choosing the I/O style for the platform.
Shopping cart service for a global e-commerce site. Users add items from mobile, web, and tablet; some sessions are offline.
Primary Postgres in us-east-1 replicating to a us-west-2 standby for DR. Writes are user-facing checkout transactions.
Write-heavy time-series workload, 100k writes/sec, can tolerate eventual reads, must stay available during single-AZ outages.
Order workflow spans 5 microservices (cart, payment, inventory, shipping, notifications), each with its own database.
A user-profile service with N=3 replicas per key, light contention, multi-region.
Tracking which of ~1500 worker nodes are alive in a batch-processing cluster.
Storage engine for a write-heavy time-series ingest service. Reads are mostly recent data; durability matters; SSDs.
User-profile service joins users, preferences, and subscription rows on almost every read. Writes are infrequent.
OLTP service mostly does single-row updates with the occasional multi-row consistency check (e.g., 'don't double-book a seat').
A reporting team wants to run hour-long aggregate queries against the same Postgres serving your checkout flow.
Choosing between Postgres-style heap tables and MySQL/InnoDB-style index-organized tables (clustered on PK) for a new schema.
Postgres `synchronous_commit`: leave it ON (fsync WAL before ack) or set it OFF (ack early, fsync later) to chase throughput.
Serving a global audience over flaky mobile networks. Pick HTTP (Hypertext Transfer Protocol) 2 or HTTP/3 at the edge.
Returning clients are hitting your API (Application Programming Interface). Do you allow TLS (Transport Layer Security) 1.3 0-RTT or require a full 1-RTT handshake?
Server expected to hold 100k concurrent long-lived connections. Thread-per-connection or event loop?
Running untrusted plugin code or risky native libraries. Process or thread?
Database is doing its own page cache and you do not want the kernel double-buffering. Buffered or direct I/O?
Load balancing across backends where request durations vary wildly (some 1ms, some 5s). Round robin or least connections?