40 questions / 10 random questions
Random questions, instant feedback, and review for missed questions.
View recommended Web & Distributed Systems Design resources →
A client may retry a payment-creation API after losing the response. Which design prevents a duplicate charge?
Answer: Persist a client-provided idempotency key and return the previous result for the same key and request
Atomically associating an idempotency key with the business result maps a retry after response loss to the original operation. Define key retention and reject reuse of a key with different request content.
A required field must be introduced to a public API. Which rollout minimizes breakage of existing clients?
Answer: First add it as optional with a default behavior, observe adoption, and require it only in a new version
Evolve APIs through additive backward-compatible changes and a measured migration period. Contract-breaking changes belong in an explicit new version with a deprecation plan.
A frequently updated large dataset is paged through an API. Which method reduces deep-OFFSET latency and cross-page duplicates?
Answer: Use a cursor containing the last key under a stable unique ordering
With a unique order such as creation time plus ID, keyset pagination seeks after the previous last row, enabling index seeks and reducing effects from concurrent inserts.
An API should allow short bursts per client while limiting the average request rate. Which algorithm is appropriate?
Answer: Use a token bucket and return 429 with Retry-After when the limit is exceeded
A token bucket refills at a fixed rate and permits bursts up to accumulated capacity. Define the limit by user, API key, or tenant and return 429 with retry guidance.
An upstream API has 800 ms remaining and calls two downstream services sequentially. Which timeout design is appropriate?
Answer: Propagate the overall deadline and give each call a budget shorter than the remaining time
Propagate the entry deadline and allocate downstream budgets after reserving time for network and response processing. Cancel useless work after expiration to release resources.
How should clients retry transient 503 responses without synchronizing load on the failing service?
Answer: Limit attempts, add jitter to exponential backoff, and retry only idempotent operations
Exponential backoff spreads attempts over time and jitter desynchronizes clients. Bound eligible failures, total time, and attempts; non-idempotent operations require idempotency control.
A downstream service is failing repeatedly. Which mechanism protects caller resources while still probing for recovery?
Answer: Open a circuit breaker to fail fast, then allow limited probes in half-open state
A circuit breaker opens based on failure conditions and short-circuits calls likely to fail. After a delay, limited half-open probes test recovery before closing the circuit.
A low-priority reporting API must not exhaust a connection pool and stop a critical payment API. Which design is appropriate?
Answer: Apply bulkheads with separate thread, connection, or concurrency limits per function
Bulkheads isolate resources like ship compartments so saturation in one function does not consume another's capacity. Size pools or semaphores according to criticality.
Events arrive faster than consumers can process them. Which backpressure design avoids memory exhaustion?
Answer: Use bounded queues and flow control with defined producer throttling, rejection, or delay policies
Keep capacity finite and define full-buffer behavior in the API, broker, or reactive-stream contract. Depending on criticality, use 429, producer blocking, durable queuing, or load shedding.
When a dependency database is down, pods should stop receiving traffic without entering a restart loop. Which probe design is appropriate?
Answer: Use liveness for process health and readiness for ability to serve traffic including dependencies
Liveness represents a process fault recoverable by restart; readiness represents current ability to serve. A shared database outage is not fixed by restarting pods, so remove them through readiness.
If both Regions continue accepting writes during a network partition, what tradeoff must be accepted under CAP?
Answer: Temporary inconsistency and conflict resolution after recovery
When partition tolerance is required and both sides remain available, they cannot immediately observe each other's writes, so strong consistency cannot also be guaranteed. Conflict handling must match business semantics.
A user reads stale replica data immediately after updating an order. Which approach provides read-your-writes consistency?
Answer: Route that user to the primary briefly or wait for a replica that has reached the written version
Track the version or log position returned by the write, then read from the primary or a replica that has caught up to that position so the user observes their own write.
Order, payment, and inventory are owned by separate services. Which design handles business failure without a distributed transaction?
Answer: Use a saga of local transactions with defined compensating actions
A saga combines local transactions with events or commands and performs semantic compensation such as refunds or inventory release after downstream failure. Compensation itself must be idempotent.
A database update can commit while publishing to the event broker fails. Which pattern addresses this dual-write problem?
Answer: Save the business update and outbox row in one database transaction, then relay it to the broker
A transactional outbox commits the event intent atomically with business data. A relay retries unsent rows, and idempotent consumers handle possible duplicate publication.
A broker can redeliver the same event. Which consumer design ensures the business side effect is not repeated?
Answer: Put a unique constraint on event ID and atomically save the processed record with the business update
At-least-once delivery treats duplicates as normal. Persisting a deduplication key in the same transaction as the business change survives crashes and lost acknowledgements.
Why is idempotency still needed for an external database update even when a broker advertises exactly-once delivery?
Answer: Broker guarantees do not automatically include atomicity with an external database, and replay can occur around commit and acknowledgement
Clarify the guarantee boundary. Even with broker transactions or deduplication, a crash after external commit but before acknowledgement can replay processing, so business effects must be idempotent.
Order events must stay ordered per customer while different customers process in parallel. What should be the partition key?
Answer: customerId
Routing the same customerId to one partition preserves that customer's order while different customers execute across partitions. Monitor for hot-key distribution.
One message fails repeatedly and blocks queue progress. Which operation is appropriate?
Answer: Move it to a DLQ after bounded attempts and define diagnosis, alerting, and redrive procedures
A poison message should be isolated in a DLQ after bounded retries so healthy traffic progresses. Monitor DLQ depth and oldest age, then redrive safely after remediation.
A new field is added to an event schema. Which approach preserves compatibility with old consumers?
Answer: Add the field as optional or with a default and let consumers ignore unknown fields
Events need forward- and backward-compatible schema evolution so producers and consumers deploy independently. A schema registry and compatibility rules can detect breaking changes.
Writes use a normalized model while search uses a separate precomputed model. Which pattern fits?
Answer: Use CQRS to separate command and query models and synchronize them through events
CQRS separates write invariants from read shapes. Because query-model updates are often asynchronous, define lag, rebuild procedures, idempotency, and the source of truth.
What is the standard cache-aside flow for retrieving product data?
Answer: Read cache, load from the database on a miss and populate cache, then invalidate cache on updates
In cache-aside, the application coordinates cache and the authoritative database. It lazy-loads misses and commonly invalidates entries after database commit for reconstruction on the next read.
A hot cache key expires and many requests hit the database simultaneously. Which control mitigates the cache stampede?
Answer: Use per-key single-flight loading, TTL jitter, and proactive refresh where appropriate
Single-flight lets one loader refresh while other requests wait, suppressing duplicate work. Jitter spreads expiration of many keys over time.
A race between database updates and cache invalidation can repopulate stale data. Which design reduces this risk?
Answer: Invalidate after commit through an event and combine it with versioned values or bounded TTL
Invalidation based on committed changes plus version comparison helps prevent late stale values from overwriting new ones. Decide whether strict synchronization or bounded staleness is required.
A CDN must safely cache responses that vary by language and compression. Which cache-key design is appropriate?
Answer: Include path, relevant query values, and only language and encoding headers that actually vary the response
Include only inputs that vary the response. Too few causes data mixing; too many destroys hit rate. Avoid caching personalized responses or partition them safely.
A cache node is added. Which distribution method avoids remapping most keys?
Answer: Use consistent hashing with virtual nodes
Consistent hashing assigns keys to nearby nodes on a hash ring, limiting movement when nodes change. Virtual nodes improve balance among physical nodes.
A multi-tenant order database is sharded. Queries are mostly within one tenant and cross-tenant joins are rare. Which shard key is appropriate?
Answer: Base sharding on tenantId, with additional partitioning for very large tenants
Co-locating data by tenantId aligns with the main access pattern and keeps most queries within one shard. Plan for tenant-size skew and rebalancing.
A system has lagging read replicas, but inventory confirmation immediately after reservation requires the latest value. Which routing is appropriate?
Answer: Route consistency-sensitive reads to the primary or a caught-up replica, and ordinary reads to replicas
Classify read requirements. Inventory and authorization paths use the primary or a replica caught up to the required position, while ordinary views can tolerate lag for scale.
For five replicas, which read and write quorum condition guarantees overlap?
Answer: Choose R and W so that R + W > 5
For N replicas, R + W > N ensures at least one overlap between read and write sets. W > N/2 also overlaps concurrent write quorums. Version comparison is still required.
An old leader continues writing after a partition while a new leader is elected. Which mechanism prevents split-brain writes?
Answer: Issue monotonically increasing fencing tokens and have storage reject writes with older tokens
A process can continue or resume after its lease expires. The downstream storage must validate an epoch or fencing token and reject stale leaders to preserve safety.
A batch acquires a leased distributed lock. Which implementation consideration is required for safety?
Answer: Handle lease expiry, renewal failure, and clock assumptions, and use fencing tokens for critical writes
Distributed locks need expiry for crash recovery, but a paused owner may resume after expiry. Do not rely on the lease alone; reject stale tokens at the write target.
An HTTP service must scale horizontally and allow routing to any instance. Which design is appropriate?
Answer: Keep service instances stateless and store session state in a shared store or signed token
Removing instance-local state lets the load balancer route to any healthy instance and simplifies scale-out, restart, and deployment. Shared session stores still need availability and TTL design.
A shared session store can affect every web instance when it fails. Which mitigation is appropriate?
Answer: Make the store highly available and design timeouts, capacity, eviction, and reauthentication behavior
A shared store becomes a centralized dependency. Add replication and failover, short timeouts, suitable TTL and capacity monitoring, and fail safely to reauthentication when necessary.
Two active Regions can concurrently update the same user profile. Which design is required?
Answer: Define conflict detection and field-level merge or explicit precedence rules
Active-active systems permit concurrent writes under latency or partition. Choose conflict rules suited to the data, such as version tracking, timestamps, CRDTs, or business-level merge.
What must be considered when DNS failover moves traffic from a failed Region to a standby Region?
Answer: TTL and resolver caches make failover noninstantaneous, so plan for overlapping traffic to both sites
DNS answers are cached by recursive resolvers and clients, so traffic splits across old and new endpoints during transition. Exercise TTL, health checks, data RPO, sessions, and failback.
One user request passes through an API gateway, services, a queue, and a worker. How should it be traced end to end?
Answer: Propagate trace context through HTTP and message headers and record a common trace ID on spans
Propagate a standard such as W3C Trace Context across boundaries and connect synchronous and asynchronous work as spans. Apply sampling and data masking and correlate metrics and logs.
What is the purpose of an error budget for a service with a 99.9% availability SLO?
Answer: Quantify acceptable unreliability and use it to balance release velocity against reliability work
The error budget is the gap between 100% and the SLO, representing allowed failure over a window. Fast burn triggers reliability work; remaining budget supports controlled change.
Average latency is 100 ms, but some users wait several seconds. Which metric is most useful for improvement decisions?
Answer: Examine p95 and p99 percentiles by endpoint and Region
Percentiles expose slow tail experiences. Averages are diluted by many fast requests, so combine p95/p99 with traffic, errors, and dependency spans.
How should a chaos test that intentionally stops service instances be run safely in a production-like environment?
Answer: Define steady-state hypotheses, scope, abort conditions, monitoring, and rollback, then start small
Chaos engineering is a controlled hypothesis-driven experiment, not random destruction. Limit blast radius and use automated aborts and observability to discover weaknesses safely.
A system receives 200 requests per second with an average processing time of 0.5 seconds. Under Little's Law, what is the average number in the system?
Answer: 100 requests
Little's Law gives L=lambda times W: 200 requests/second times 0.5 seconds equals 100 requests. Capacity still needs headroom for peaks, variance, and queueing.
An asynchronous worker has low CPU but rapidly increasing queue delay. Which autoscaling signal is appropriate?
Answer: Use queue depth or oldest-message age together with worker count and processing rate
I/O-bound workers can accumulate backlog without high CPU. Tie queue length per worker or oldest age to the SLO and account for startup time and in-flight work during scale-in.