70 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: Store an idempotency key and return the previous result for the same 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: Add it as optional with defaults, then require it 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 with the last key under a stable unique order
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 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 budget each call below 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 and retry only idempotent operations with jittered backoff
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: Fail fast with a circuit breaker and probe 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 per-function connection and concurrency limits
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 throttling and rejection 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 serving ability
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 to the primary briefly or wait for a caught-up replica
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 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 update and an outbox row in one transaction, then relay it
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 the event ID and save the record and update atomically
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 exclude atomicity with an external database, so replay can occur
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: The customerId that identifies the customer
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 with diagnosis 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 it 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: Separate command and query models with CQRS and sync via 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 invalidate on update
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: Combine per-key single-flight loading with TTL jitter
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 via an event, with versioned values or short 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, query, and only the 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: Shard on tenantId and consider extra partitioning for huge 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: Send consistency-sensitive reads to the primary or a caught-up replica
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: Reject stale writes with monotonically increasing fencing 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 and renewal failure and fence 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 services stateless and hold sessions 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 redundant and design timeouts, eviction, and reauthentication
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: Conflict detection with 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 delay failover, so plan for 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
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: To quantify acceptable unreliability and guide release decisions
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
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 hypotheses, scope, abort conditions, 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: Combine queue depth or oldest-message age with 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.
Multiple users edit the same document, and a save from a stale screen must not overwrite newer changes. Which HTTP API design is appropriate?
Answer: Return an ETag on reads and 412 when If-Match does not match
Conditional updates with ETag and If-Match provide optimistic concurrency control by comparing the version read by the client with the current version. A mismatch prompts reload or merge.
An HTTP API accepts a video conversion that takes several minutes. Which asynchronous API design is appropriate?
Answer: Return 202 Accepted with an operation URL exposing status and result
202 indicates acceptance, not completion. An operation resource should expose progress, a final-result link, failure details, polling guidance, and cancellation where supported.
A product-list API should briefly serve stale cache content during an origin failure to preserve availability. Which cache policy is appropriate?
Answer: Configure bounded stale-if-error and define freshness requirements
stale-if-error permits reuse of expired responses for a bounded time when the origin fails. Acceptable staleness must be decided per data type, such as catalogs versus balances.
An upstream gRPC request has 500 ms remaining on its deadline. How should a downstream RPC be invoked?
Answer: Propagate a deadline within the remaining budget and stop on cancellation
Propagating the end-to-end deadline budget prevents resource use after the upstream can no longer consume the result. Reserve time for processing at each hop.
Hedged requests are being considered to reduce tail latency for a read-only search. How should they be introduced safely?
Answer: Duplicate once after a high-percentile delay and cancel the loser
Hedging can mask a slow replica but added traffic may amplify an outage. Restrict it to read-only or idempotent operations and enforce delay thresholds, budgets, and cancellation.
A service is saturated and queue latency is crossing its SLO. What should it do before accepting everything causes a total outage?
Answer: Limit concurrency and shed low-priority requests early with 503 and Retry-After
Load shedding rejects work beyond capacity early, preserving critical traffic and recovery headroom. Design priorities, admission limits, retry guidance, and monitoring together.
What is wrong with assuming internal services need no authorization because the API gateway validated the JWT?
Answer: Each service should still verify principal, permission, and ownership against bypasses
A gateway is useful perimeter control, but each service owns authorization for its business resources. Verify issuer, audience, expiry, scopes, and ownership, not only signature.
Which design appropriately mitigates SSRF in a feature that fetches images from user-provided URLs?
Answer: Validate allowed hosts, reject internal IPs after DNS resolution, and restrict egress
SSRF abuses server network privileges to reach internal services or cloud metadata. Combine consistent URL parsing, post-resolution IP checks, redirect revalidation, and an egress allowlist.
Long-lived static certificates make a service-to-service mTLS credential leak highly damaging. Which operation is appropriate?
Answer: Automatically issue and rotate short-lived certificates from workload identity
Short-lived credentials and automatic rotation reduce the compromise window while preserving per-service identity. Monitor issuance failures, approaching expiry, and authentication errors.
A client caches service-discovery DNS results for its entire process lifetime and never switches to new instances. What is the appropriate improvement?
Answer: Honor DNS TTL, re-resolve, balance across addresses, and refresh connections
Discovery results have a lifetime. Understand DNS caching in the client runtime and connection pool, then design TTL handling, re-resolution, and connection maximum age.
In-flight requests are disconnected when pods terminate during a rolling update. Which graceful-shutdown design is appropriate?
Answer: Remove from traffic, drain in-flight work after SIGTERM, and set a grace period
Remove terminating pods from load balancing, let the application handle SIGTERM, stop new admission, and finish in-flight work within the deadline. Long jobs also need resumability.
A new version is sent to a 5% canary. Which automated promotion or rollback decision is appropriate?
Answer: Compare error rate, latency, and KPIs with the old version under equal conditions and decide by thresholds
Canary analysis evaluates technical and business signals against a control. Predefine minimum samples, observation windows, and immediate rollback conditions to avoid low-traffic noise.
Production requests will be shadowed to a new recommendation service for comparison. How can this be done safely?
Answer: Do not return shadow responses and disable writes and external notifications
Traffic mirroring tests a new implementation with production-shaped input, but side effects must be isolated. Design PII masking, sampling, added capacity, comparison IDs, and retention.
Disaster recovery defines RPO of five minutes and RTO of thirty minutes. What does that mean?
Answer: Allow about five minutes of data loss and target recovery within thirty minutes
RPO describes tolerable data loss back to the recovery point; RTO is the target time to restore service. Requirements drive replication, backup, failover automation, and dependency order.
Daily backup jobs report success, but restorability during a disaster is uncertain. What is the most important additional measure?
Answer: Regularly restore into an isolated environment and measure integrity and RPO/RTO
A successful backup does not guarantee a successful restore. Restore drills uncover corruption, schema/version mismatch, key and permission issues, dependencies, and actual recovery time.
Rebuilding an event-sourced projection replayed historical external notifications. What separation is appropriate?
Answer: Keep projections side-effect-free and separate notifications into their own process
A replayable projector should derive the same state from the same event sequence without side effects. Notifications need a separate outbox or delivery ledger that tracks delivery intent.
An API fans out to twenty downstream services, and one slow dependency worsens overall tail latency. Which design is appropriate?
Answer: Parallelize required calls with a shared deadline and partial-result policy
Fan-out aggregates dependency tails and failure probabilities. Shorten the critical path using deadline budgets, bulkheads, fallbacks, dependency reduction, or aggregated read models.
What is wrong with putting an access token in OpenTelemetry baggage and propagating it to every service?
Answer: Baggage can propagate to external headers, so exclude secrets and control keys
Baggage carries context across processes but does not automatically provide confidentiality or integrity. Strip it at external boundaries and use authenticated claims for trust decisions.
Measuring cross-service duration solely from host wall-clock differences produces negative latency. What is the appropriate approach?
Answer: Use a monotonic clock in-process and account for skew in traces
Wall clocks move due to NTP corrections and host skew. Use monotonic clocks for local duration and trace IDs, parent spans, and event ordering for cross-service causality.
Many identical expensive product searches arrive simultaneously and all execute the same downstream query. Which request-coalescing design is appropriate?
Answer: Share in-flight work per normalized key and fan out the result
Singleflight-style coalescing combines concurrent misses for one key into one unit of work. Include authorization context in the key and define sharing scope, cancellation, and error caching.
An authenticated API returns sensitive data that compliant HTTP caches must not store. Which Cache-Control directive fits?
Answer: Use no-store to prohibit storage of the response.
no-store prohibits caching this response; no-cache instead requires validation before reuse. Neither is a guarantee of erasing previously retained data or controlling application-managed storage.
A client with a stored body and ETag sends a GET with If-None-Match and receives 304. What should it do?
Answer: Reuse the matching stored body and update metadata from the response.
304 confirms the stored representation is reusable and carries no content. Reuse its body and update the relevant cache metadata.
A POST is temporarily redirected within the same origin. Which status preserves its method and body when automatically followed?
Answer: Return 307 to preserve POST when following it.
307 denotes a temporary redirect without changing the method when followed. A 302 can permit POST to become GET.
A safely retryable GET receives 429 with Retry-After: 30, but the client has only five seconds of remaining budget. What should it do?
Answer: Stop synchronous retries and return a result allowing a later attempt.
The value requests a 30-second delay, beyond this call's budget. Stop synchronous retries instead of ignoring the server's guidance; later execution needs an explicit application policy.
A webhook signs the raw body bytes. Verifying reserialized JSON rejects legitimate notifications. Which fix is appropriate?
Answer: Preserve the original body bytes and verify using the sender's scheme.
Whitespace or key order can change signed bytes without changing JSON meaning. Verify the original body with the specified headers before processing it.
A webhook signs its body together with a timestamp. What should be added to reject captured old notifications replayed unchanged?
Answer: Validate the signed timestamp and reject notifications outside the allowed window.
A replay can retain a valid signature. Check signed freshness against a reliable clock, and separately deduplicate event IDs for repeats inside the allowed window.
A signed pagination cursor contains a tenant ID and position. Another tenant submits a valid cursor it obtained. What must the API do?
Answer: Check the caller's authorization for the tenant and reject cross-tenant access.
A cursor signature protects integrity, not the holder's authority. Authorize each page request and ensure cursor scope matches the caller and query.
Under JSON Merge Patch (RFC 7396), what is the result of applying {"name":"New","phone":null} to {"name":"Old","phone":"123"}?
Answer: name changes, and the phone member is removed entirely.
In JSON Merge Patch, null in an object removes that member; omitted members remain unchanged. An API needing literal null values should consider a different update representation.
A successful DELETE returns 204 No Content. The client fails because it parses every 2xx response as JSON. Which fix fits?
Answer: Skip body parsing for 204 and handle the operation as successful.
204 is successful but has no content. Skip JSON parsing for it, or use an appropriate content-bearing status if the API needs a JSON response.
In synchronous A→B→C calls, A attempts B at most three times and B attempts C at most three times per request. C always fails and time permits all attempts. What is the maximum C load per request to A, and a suitable improvement?
Answer: At most nine calls; define retry ownership and a shared total budget.
Three B attempts each generate three C attempts, giving nine. Layered retries multiply load. Assign retry ownership and bound the total time and attempt budget while considering idempotency.