System Design Interview Practice Questions

During a flash sale, a commerce API kept returning success on its status endpoint and stayed behind the load balancer after its connection pool to the stock reservation store wedged. Instances still accepted HTTP connections, so scaling added more unusable capacity while checkout attempts failed until operators drained nodes manually. Which change is the safest next decision?

1. AA. Use a cheap process probe for restarts, a bounded reservation-store exercise for traffic admission, and scheduled synthetic checkouts against the recovery route.
2. BB. Use a cheap process probe for restarts, drain only after real checkout errors exceed a threshold, and run manual recovery tests after incidents.
3. CC. Use the existing status endpoint for restarts, require only an HTTP accept check for traffic admission, and add dashboards for checkout failure rate.
4. DD. Use a deep dependency sweep for restarts, the same sweep for traffic admission, and block all regions when any dependency probe fails.

During a flash sale, the first checkout screen becomes slow even though web servers are under 40% CPU. Traces show most time is spent repeatedly reading item eligibility and amount data; those values change through controlled updates, and the final submit path already verifies the order before committing it. Which recommendation is the safest next architecture decision?

1. AA. Store complete checkout pages at the edge per shopper, purge them every minute, and keep final submission checks on the authoritative store.
2. BB. Serve a short-lived read copy for item quote inputs, refresh it on controlled updates, and keep final submission checks on the authoritative store.
3. CC. Cache completed reservation decisions for duplicate carts, reuse them for later attempts, and keep final submission checks on the authoritative store.
4. DD. Memoize each web server's last quote responses, expire entries quickly, and keep final submission checks on the authoritative store.

A profile service emits account updates used by cache eviction, risk scoring, and monthly reconciliation. Adding a new processor currently changes which existing processor receives some updates, and correcting a processing bug requires expensive database backfills. Which architecture decision is the safest next step?

1. AA. Use a durable work queue partitioned by account, let processors compete for messages, and retry failed tasks with dead-letter handling.
2. BB. Use separate durable work queues per processor, copy each update to every queue, and scale consumers independently with per-queue retries.
3. CC. Use immediate fan-out notifications to all processors, partition by account, and rely on each processor's local store for missed updates.
4. DD. Use an append-only event log with retention, partition by account, give each processor its own cursor, and require idempotent downstream writes.

A ticketing marketplace keeps live seat state during major onsales. The busiest operations mutate or render small seating areas within one show, while account-support lookups by buyer happen rarely and can lag. A prior design spread records by buyer and made each onsale fan out across many ranges, causing slow map refreshes and lock contention. Which storage layout is the safest next decision?

1. AA. Group seat-state rows by show area, order by seat, and maintain an asynchronous buyer lookup view for support workflows.
2. BB. Group seat-state rows by seat identifier hash, order by show, and rebuild each live seating area from scatter-gather reads.
3. CC. Group seat-state rows by buyer, order by purchase time, and query all affected buyers when refreshing a live seating area.
4. DD. Group seat-state rows by venue and calendar day, order by show, and filter seating areas inside each larger range.

An appointment platform sends provider notifications for scheduled visits. During regional failover, two scheduler replicas sometimes pick the same due visit. Duplicate sends can create conflicting provider commitments; a delayed send can be retried. A worker can also crash after the provider accepts a notification but before local completion is recorded. Which near-term design best protects the business invariant before traffic increases?

1. AA. Let every active replica send due notifications immediately, then reconcile duplicate provider commitments after failover by canceling extras.
2. BB. Add worker concurrency limits, retry backoff, and backlog alerts so failover sends less duplicate traffic under load.
3. CC. Partition visits by provider, run one scheduler per partition, and manually rebalance partitions during regional failover.
4. DD. Claim each due visit with a guarded state transition, send with a stable notification key, and reconcile accepted send outcomes before retrying.

A typeahead product adds a generated rewrite step before querying its index. A stricter input-hardening change is ready, but previous revisions caused rewrite latency spikes; client retries then saturated the search tier. Product accepts losing speculative suggestions briefly, but submitted searches must receive an explicit outcome. Which architecture decision is safest?

1. AA. Run the hardening change on a small traffic slice, cache rewrite results aggressively, let committed searches wait behind suggestions, and roll back on error-rate alarms.
2. BB. Disable client retries, run the hardening change globally, prioritize committed searches in workers, and use manual operator approval before rejecting any request.
3. CC. Run the hardening change on a small traffic slice, cap speculative rewrites, return explicit busy responses for committed searches, and roll back on queue age or retry-rate alarms.
4. DD. Deploy the hardening change globally, increase rewrite worker concurrency, keep all requests queued, and alert only when search-tier latency exceeds its target.

A ticketing checkout endpoint now has 4-second p95 latency after adding receipt generation, recommendation updates, and partner notifications. The page cannot advance until the customer is told accepted or declined, and confirmed seats must never be double-sold. Which architecture change is the safest next decision?

1. AA. Run payment, seat claim, order record, receipts, recommendations, and notifications concurrently; respond once payment and any one persistence write succeeds.
2. BB. Keep all checkout work before responding, but add more application instances and per-dependency timeouts for receipts, recommendations, and partner notifications.
3. CC. Return a provisional confirmation after payment authorization; perform the seat claim, order record, receipts, recommendations, and notifications asynchronously with compensating cancellation if needed.
4. DD. Complete payment authorization, atomic seat claim, and order record before responding; hand off receipts, recommendations, and partner notifications durably with retries and lag alerts.