All 74 System Design quiz questions below come with a short explanation, visible right on the page — no sign-in needed. They're grouped by beginner and intermediate levels and 25 subtopics, so you can revise one part at a time. Choose Try System Design quiz above to take a scored run and review the questions you got wrong.
How does the cache-aside (lazy loading) pattern work?
A.Preload the whole dataset into the cache at startup
B.Write to the cache and the DB together on every write
C.The application reads only the cache while a background job syncs it from the DB
D.Read the cache first; on a miss read the DB and write the result back into the cache
Answer: D
Read cache first; on miss, read the DB, write the result into cache with a TTL, then return. Only data actually requested enters the cache — simple and economical, so it's the default pattern.
Should a confirmation email after checkout be sent inline or pushed to a queue?
A.Synchronously, so the user certainly has the mail before seeing the order result
B.Through a queue — an order should not fail because the mail failed
C.Synchronously but wrapped in a try-catch that swallows the error
D.Depending on load: send it synchronously when the system is idle
Answer: B
Through a queue. The core work (writing the order) and the side work (sending mail) must be decoupled: the user gets an immediate response, the mail is sent by a worker and retried if SMTP fails. An order shouldn't fail just because a mail failed.
What limitation does load balancer sticky session introduce?
A.It adds latency because a routing table is consulted per request
B.HTTPS cannot be used because the cookie must be read to route
C.Losing an instance loses the user's session, and the load spreads unevenly
D.It only works with exactly two instances behind it
Answer: C
With locally stored session state, sticky sessions pin a user to one instance: an instance dying loses the session, deploys log users out, and load skews because the instance with more "stuck" users gets heavier. The right fix is making the app stateless.
A.Split them: liveness checks the process, readiness checks the dependencies
B.Return 200 to show the process is alive and nothing else
C.Run a real business query to be sure everything still works
D.Check every dependency in one single endpoint
Answer: A
Split into two. Liveness: the process is running and not hung → fail means restart. Readiness: DB connected, cache connected, config loaded → fail means remove from the load balancer but do not restart.
A page listing 50 orders issues 51 queries. What is this problem called?
A.The N+1 query problem — each record triggers an extra sub-query
B.Missing indexes so each query scans the whole table
C.The transaction was split into several smaller statements
D.The connection pool is too small so queries are split up
Answer: A
N+1 query: 1 query to fetch the list, then 50 queries to fetch related data for each row. Fix it with a JOIN, or batch preloading: collect all the ids and run one WHERE order_id IN (...) query.
A worker fails midway through a queue job. What should happen to the job?
A.Move it to the back of the queue with a lower priority
B.Retry indefinitely until it eventually succeeds
C.Discard it so it does not block the jobs behind it
D.Return it to the queue for a retry, and after N attempts move it to a dead-letter queue
Answer: D
Return it to the queue and retry with a limit (with backoff); after N attempts, move it to a dead-letter queue for operators to inspect. Both extremes are wrong: dropping it loses work, retrying forever jams the queue.
D.Orchestrating the call order between services in a flow
Answer: A
Cross-cutting concerns at the edge: TLS termination, token authentication, rate limiting, routing, access logging, and sometimes response aggregation. That way backend services focus purely on their business logic.
What is the main architectural benefit of a message queue?
A.Removing the need for error handling in the consumer
B.Reducing an operation's latency compared with a direct call
C.Decoupling the two sides and absorbing load spikes
D.Guaranteeing each message is processed exactly once
Answer: C
A queue decouples the sender from the processor: the request returns as soon as the message is written, and the heavy work runs in the background. It also absorbs traffic spikes — messages wait in line instead of overloading the processor.
What does at-least-once delivery imply for the consumer?
A.The sender must check whether the message arrived
B.No dead letter queue is needed since messages always arrive
C.The processor must tolerate duplicate messages
D.Messages are always processed in the order they were sent
Answer: C
The consumer must be idempotent: processing the same message twice must produce the same result as processing it once. This happens when the consumer finishes but the acknowledgement is lost, so the system redelivers that message.
When does least-connections load balancing fit better than round robin?
A.When every request takes the same amount of time
B.When users must stay on the same server
C.When the servers all have identical specifications
D.When request processing times vary widely
Answer: D
It fits when processing times vary widely: round-robin keeps sending new requests to a machine still handling long requests. Splitting by the number of open connections reflects actual load better in that situation.
What problem does a hot key cause in a cache system?
A.Other keys are evicted to make room for it
B.That key's value expires faster than normal
C.One node bears all of that key's traffic
D.One value consumes the whole cluster's memory
Answer: C
Because the key maps to a single fixed node, all access to it piles onto that node and adding nodes to the cluster doesn't spread the load. Handling: replicate the key into multiple copies, or cache at the application layer so most accesses don't reach the cluster.
A.They are the same thing with different names by organization
B.An SLI is the measured figure, an SLO the target, an SLA the commitment
C.An SLA is the measured figure and an SLO the customer commitment
D.SLIs and SLOs are internal while SLAs apply only to infrastructure
Answer: B
SLI is a measurable metric (success rate, latency at the 99th percentile). SLO is an internal target for that metric (99.9% over 30 days). SLA is a customer commitment with consequences if breached — usually set looser than the SLO to keep a safety margin.
How does a backend for frontend differ from a general API gateway?
A.A BFF runs on the user's machine rather than on the server
B.A BFF only handles authentication and rate limiting
C.A BFF fully replaces the need for the services behind it
D.Each client type gets its own layer aggregating data to its needs
Answer: D
A BFF is a separate layer per client type: web, mobile, partners. Each layer aggregates data from the services and returns exactly the shape that client needs. A general API gateway serves all clients with one set of endpoints and focuses on auth, routing, and rate limiting.
A.Authenticating a service's identity when they call each other
B.Monitoring each service's health
C.Finding the addresses of running instances without hardcoding them
D.Load balancing across a service's instances
Answer: C
It answers the question which addresses service X is running on. Instances are created and destroyed continuously in an elastic environment, so the address list must be updated dynamically instead of hardcoded in configuration.
How should messages in a dead letter queue be handled?
A.Keep them forever so they can be looked up later
B.Automatically return them to the main queue after a delay
C.Delete them periodically so the queue does not fill up
D.Alert, investigate, then reprocess or discard deliberately
Answer: D
There must be alerting when a message arrives, a process to investigate the root cause, and tooling to reprocess after a fix or deliberately discard with a recorded reason. An error queue nobody watches is just where data silently disappears.
A.Distributing keys evenly across the nodes in a cluster
B.Ordering data by how recently it was accessed
C.Storing compressed data to save memory
D.Quickly checking that an element is definitely absent
Answer: D
A Bloom filter answers existence questions with the property never reporting a false negative: if it says absent, it is definitely absent; if it says present, it may be wrong. It is used to avoid an expensive lookup when most answers are non-existent.
How does horizontal scaling differ from vertical scaling?
A.Horizontal is for applications and vertical for databases
B.Vertical is always faster because there is no network latency between machines
C.Horizontal adds machines while vertical raises one machine's specification
D.Horizontal is cheaper than vertical in every case
Answer: C
Horizontal means adding machines and spreading load across them — no hard ceiling and built-in fault tolerance, but it requires the application to hold no local state. Vertical means upgrading a single machine — simplest, but you hit the hardware ceiling and that machine remains a single point of failure.
Because every instance is equivalent: any request can be handled on any machine, so the load balancer can distribute freely, adding or removing machines doesn't drop anyone's session, and a failed machine only affects in-flight requests.
A.The browser, the CDN, the application tier and the database
B.One shared cache layer is enough
C.Caching in the browser is enough for every kind of content
D.Only cache at the database, since that is where the data lives
Answer: A
Four common layers: browser (static assets), CDN (shared content, close to users), application layer (query results, computed data), and database (page cache, query plans). The closer the cache is to the user, the more it saves.
A.To give priority to clients that have waited longer
B.To detect the service's recovery sooner
C.So the clients do not all retry at the same instant
D.To reduce each client's total number of retries
Answer: C
Without random jitter, every client that fails at the same time will retry at the same time, creating load spikes exactly when the service is trying to recover. Adding randomness to the wait spreads retries evenly over time.
A third-party API call times out. What is wrong with retrying immediately three times?
A.It loses the first call's result if that call actually succeeded
B.Retrying never helps with a network timeout
C.It violates HTTP semantics so retrying is not allowed
D.It piles more load onto an already overloaded service and makes it worse
Answer: D
Immediate, rapid retries pile more load onto an already overloaded service, turning a small incident into a prolonged outage. You need exponential backoff + jitter: wait longer each time, plus a random interval so many clients don't all retry at once.
A user double-clicks pay because the network is slow. How do you prevent a double charge?
A.The client generates an idempotency key and the server stores the result under it
B.Use a database transaction around the whole payment flow
C.Check whether a transaction already happened in the last 5 seconds
D.Disable the button after the first click
Answer: A
Idempotency key: the client generates a unique key for each payment intent and sends it with the request. The server stores (key → result); a later request with the same key returns the previous result without charging again.
A database reads 20× more than it writes and is overloaded. The sensible first step?
A.Move to a NoSQL database for speed
B.Double the machine size each time it hits a resource limit
C.Add a read replica and route the read queries to it
D.Shard the data across several clusters right away
Answer: C
Before even a replica: check indexes and slow queries — most "DB overload" is a few queries missing an index. Then add a read replica for read load, and caching for repeated queries. Sharding is the last step.
A.It caps how many requests each client may send per minute
B.It retries failed requests automatically until they succeed
C.It balances load across several instances of a service
D.It stops calling a failing service so resources are not wasted waiting
Answer: D
Stops cascading failures: when a dependent service keeps failing, the breaker opens and fails fast instead of letting every request wait for a timeout. That way the thread pool isn't exhausted and your service can still serve other flows.
For a 10-million-row list, a user reaches page 5000. What is wrong with OFFSET 100000 LIMIT 20?
A.OFFSET has a maximum so the query errors out
B.The results come back in the wrong order with a large OFFSET
C.The DB must scan and skip 100000 rows, so deeper pages get slower
D.It is only slow when there is no index on the sorting column
Answer: C
The DB still has to scan and discard 100000 rows before returning the 20 it needs — time grows with page depth. Use cursor/keyset: WHERE (created_at, id) < (:lastCreatedAt, :lastId) ORDER BY created_at DESC, id DESC LIMIT 20.
The server must push notifications to clients that send nothing back. Simplest choice?
A.Server-Sent Events (SSE) over ordinary HTTP
B.WebSocket for a fully bidirectional connection
C.Long polling, holding the request open until data arrives
D.Poll every 2 seconds for the latest notifications
Answer: A
SSE: one-way server→client over plain HTTP, the browser reconnects on its own and sends Last-Event-ID to resume where it dropped. Simpler than WebSocket, and easier to get through proxies and CDNs.
A.The server issues a presigned URL and the client uploads straight to storage
B.Store the file in a blob column in the database
C.Save it to the server's disk and have a background job push it to storage
D.The client sends the file to the server, which forwards it to S3
Answer: A
Presigned URL: the server authenticates and issues a time-limited URL, the client PUTs directly to S3/R2. The server never holds 500MB in memory or bandwidth, and the upload isn't limited by request timeout.
Splitting a monolith into microservices — separate databases or one shared database?
A.Separate databases, with other services fetching data through APIs or events
B.A shared database with a separate schema per service
C.A shared database to avoid syncing data between services
D.It depends on scale: under 10 services, share it
Answer: A
A separate DB per service (database per service). A shared DB is the most common trap: if two services read and write the same table, a schema change requires a simultaneous deploy — you pay the cost of microservices without the benefit of independent deploys.
Where should rate limiting live in a system with an API gateway and several services?
A.Only at the gateway, since it is the single entry point
B.At the gateway for the global limit, plus in services for expensive endpoints
C.At the CDN layer, since every request passes through it
D.Only in each service, since it understands its own resources best
Answer: B
Both layers. The gateway sets global limits by IP/token to block abuse early; each service adds limits for expensive endpoints (report exports, AI model calls, sending mail). A single layer always lacks one of the two perspectives.
How should timeouts be set for internal service calls?
A.Use the HTTP client library's default value
B.As long as possible so no request fails unfairly
C.Exactly the same as the user request's timeout
D.Short and explicit, based on the measured p99
Answer: D
Set them explicitly, based on measured p99 plus a safety margin — not on defaults, because many HTTP clients default to waiting forever. Missing timeouts are the most common cause of cascading failure from one service to another.
What does a CDN do for a dynamic, per-user JSON API?
A.Very little for per-user responses, but it does cut TLS latency
B.It caches the whole response and greatly reduces origin load
C.Nothing at all — CDNs are only for static files
D.It speeds up DB queries by caching near the user
Answer: A
Per-user JSON can't be cached shared, but a CDN is still useful: terminating TLS close to the user (reducing handshake time), keeping connections warm to the origin, and blocking attacks at the edge. Actual caching only applies to shared data.
Full-text search over 5 million articles — what is wrong with a leading-wildcard LIKE?
A.It can only match the keyword at the start of the text
B.It cannot use a B-tree index so it scans the whole table
C.There is a maximum search string length so it often errors
D.The results cannot be sorted by the article's creation time
Answer: B
A leading wildcard makes the B-tree index useless — the DB has to full-scan the table on every search. In Postgres use tsvector + a GIN index; pg_trgm is good for fuzzy matching.
A.A canary shifts a fraction of traffic to the new version and then increases it
B.A canary runs two identical environments simultaneously
C.Blue-green only works for applications without a database
D.A canary needs no rollback because problems are caught early
Answer: A
Canary: shift traffic gradually (1% → 10% → 50% → 100%), watching metrics at each step. Blue-green: build the new environment in parallel, then cut all traffic over at once, rolling back by pointing back to the old environment.
Two users book the last ticket simultaneously. How do you prevent overbooking at the database level?
A.Check the remaining tickets and then write the booking record
B.Take an in-memory lock in the application while booking
C.SELECT ... FOR UPDATE or an UPDATE carrying the stock condition
D.Process them one by one through a queue with a single worker
Answer: C
Let the DB be the arbiter. The simplest is a conditional update: UPDATE seats SET remaining = remaining - 1 WHERE id = ? AND remaining > 0, then check affected rows — 0 rows means sold out. Or SELECT ... FOR UPDATE to lock the row inside a transaction.
For a multi-million-row table, should the primary key be UUID v4 or auto-increment?
A.There is no difference because the DB optimizes the index for both
B.Auto-increment is always better in every use case
C.UUID v4 is always better because it is unguessable and cannot collide
D.An auto-incrementing number or UUID v7, since both increase over time
Answer: D
Pick a monotonically increasing key: auto-increment, or UUID v7 if ids must be generated client-side. Random UUID v4 makes every insert land elsewhere in the B-tree, causing fragmentation and more page writes.
Receiving a payment gateway webhook — what must you verify before processing?
A.Whether the User-Agent carries the provider's name
B.Whether the amount matches the corresponding order in your system
C.The payload's signature computed with a shared secret
D.Whether the source IP is on the provider's list
Answer: C
The signature (HMAC of the raw body with a secret). This step is non-negotiable: without it, anyone who knows the endpoint can send a "payment completed" request. Only after the signature validates should you check the amount and order status.
A cron job lives in an app with 3 instances. How do you ensure it runs once?
A.Rely on the job detecting that another copy is already running
B.Let the instance with the lowest hostname run the job
C.A distributed lock or leader election so one instance executes it
D.Stagger the run times of the three instances by a few seconds
Answer: C
Distributed lock: when the time comes, whichever instance grabs the lock (SET key NX EX ttl in Redis, or an advisory lock in Postgres) runs, the others skip. An even cleaner approach is moving the scheduler out of the app.
20 app instances × 50-connection pools against a 200-connection database. Problem?
A.The pool shrinks itself to match the database's limit
B.The 1000 total connections exceed the limit so the DB refuses connections
C.It is fine because all 20 instances rarely exhaust their pools at once
D.The DB queues the connections beyond its limit
Answer: B
That adds up to 1000 connections while the DB only accepts 200 — under high load you get "too many connections" errors. Pool size must be budgeted globally: instances × pool ≤ limit, minus what's reserved for migrations and admin tools.
A request crosses 5 services and you need to follow its whole path. What is required?
A.Sync the machines' clocks so the logs share a time base
B.Log in more detail in each individual service
C.A trace id generated at the edge and propagated through every call
D.Ship every log to one place for centralized search
Answer: C
A trace id (correlation id): generated at the entry point, propagated via header on every internal call, and written into every log line. With it, one query by trace id reconstructs the whole journey.
A deploy drops some in-flight requests. What is the usual cause?
A.The process is killed with no graceful shutdown
B.The new instance starts more slowly than the old one is stopped
C.The new version processes requests much more slowly so they time out
D.The load balancer has not yet updated its list of instances
Answer: A
Missing graceful shutdown: the process gets SIGTERM and exits immediately, abandoning in-flight requests. The correct flow: receive SIGTERM → fail readiness so the LB drains traffic → wait for current requests to finish → close connections → exit.
A public API must change its response shape. Which approach breaks clients least?
A.Add the new field, keep the old one, and remove it once clients have migrated
B.Release a v2 and require every client to migrate within 30 days
C.Change the shape and notify the clients you know about
D.Return the new shape to new clients based on the User-Agent
Answer: A
An additive change: add the new field, keep returning the old one alongside it, mark it deprecated, monitor whether anyone still uses it, and only then remove it. Only cut a new version when the change truly can't be made compatible.
Which metric should you report for API performance?
A.The total number of requests handled per second
B.The maximum response time in the measurement window
C.The average response time across all requests
D.The p95/p99 percentiles, because the average hides the slowest part
Answer: D
Percentiles: p50 for the typical experience, p95/p99 for the tail. Averages hide exactly what you need to know — at 1 million requests/day, "only 1% are slow" still means 10,000 times a user had to wait.
What is a sensible cache TTL for a product listing?
A.Based on how stale the business can tolerate the data being
B.As short as possible so the data is always fresh
C.A fixed 5 minutes because it is the common standard
D.As long as possible to minimize load on the DB
Answer: A
Ask the business first: how stale can the data be before it's unacceptable? Product prices might only tolerate a few seconds, while categories can handle a few hours. Combine TTL with cache invalidation when the data changes.
Multi-tenant SaaS: a database per tenant, or one database with a tenant_id column?
A.Choose the storage per customer depending on their plan
B.A shared database with a tenant_id until there is a reason to split
C.A separate database per tenant from the start for full isolation
D.A shared database with a separate schema per tenant
Answer: B
Default to shared DB with a tenant_id column on every table: one migration for all, one place to monitor. Split it out only for specific reasons — data compliance requirements, or a large tenant needing dedicated resources.
A 15-minute JWT access token plus a long-lived refresh token — why this design?
A.To shrink the token sent with every request
B.Because the signing algorithm is only safe for a short period
C.A JWT cannot be revoked, so it must be short-lived to limit the damage
D.To force users to log in again more often
Answer: C
Because a JWT is verified by signature, not by lookup, the server has no way to invalidate an issued token. Keep its lifetime short so the abuse window is small; the refresh token is stored server-side, so it can be revoked immediately.
What is the downside of soft deletes via a deleted_at column?
A.A row marked deleted cannot be restored
B.Every query must remember the filter, and missing one exposes deleted data
C.It slows down every write to that table
D.It cannot be used with foreign key constraints between any two tables
Answer: B
Every query must add WHERE deleted_at IS NULL — forget it in one place and deleted data reappears. Unique constraints also break: a deleted user's email still blocks anyone else from reusing it.
The system is overloaded and cannot serve every request. Best response?
A.Auto-scale more instances and wait for the system to stabilize
B.Queue every request and process them in order
C.Shed load selectively so the remaining requests stay fast
D.Accept every request and let them all slow down equally for fairness
Answer: C
Load shedding: reject a portion of requests early (429/503) so the rest are served on time. Accepting everything and letting everyone time out is the worst outcome — resources are spent yet nobody gets a result.
A user updates their avatar but a reload still shows the old one. Common cause?
A.The new image has not finished processing in object storage
B.The write transaction was never committed
C.Reading from a replica that has not caught up, or a cache that was not invalidated
D.The browser lacks permission to download the new image
Answer: C
Two main suspects: replication lag (reading from a replica that lacks the new data) and cache not invalidated. Both violate "read your own writes" — whoever just wrote must be able to see their own data.
What problem does the transactional outbox pattern solve?
A.Messages are delivered more than once to consumers
B.The database write and the event publish can end differently
C.Message ordering is not guaranteed
D.The queue is overwhelmed when traffic spikes
Answer: B
It solves the case where the database write succeeds but event publishing fails (or vice versa). The event is written to an outbox table in the same transaction as the business data; a separate process reads that table and publishes outward, deleting after sending.
How does orchestrated saga differ from choreographed saga?
A.One has a coordinator while in the other the services react on their own
B.One uses a queue and the other calls directly over HTTP
C.One gives strong consistency while the other does not
D.One has compensating steps and the other does not
Answer: A
Centralized orchestration: one component knows the whole flow and calls each service in order — easy to monitor and easy to change the flow, but that component becomes a central point. Event chaining: each service reacts to the previous service's event — more loosely coupled, but no one sees the whole flow.
What does back-pressure mean in a streaming system?
A.The receiver signals the sender to slow down when it cannot keep up
B.Old messages are dropped to make room for new ones
C.The sender retries when the receiver returns an error
D.The system adds processors automatically when load rises
Answer: A
Back-pressure is the mechanism for the receiver to signal the sender to slow down when it can't keep up. Without it, buffers balloon until memory runs out, or messages are dropped — both worse than deliberately slowing down.
How do you generate distributed unique IDs that remain time-sortable?
A.Hash the record's content to form the identifier
B.Combine a timestamp, a node identifier and a counter
C.Use a long enough random number that collisions are very unlikely
D.Use an incrementing counter in a central service
Answer: B
Combine three parts: a timestamp (for ordering), a generator machine ID (to avoid collisions across machines), and a counter within the same millisecond. This is the structure of snowflake-style ID algorithms, and also the idea behind UUID v7.
How should data be synchronized from a database into a search engine?
A.Sync the whole dataset on a nightly schedule
B.Write to both within the same request
C.Emit events and update the index asynchronously
D.Query the database directly and drop the search engine
Answer: C
Update the index asynchronously via change events: write to the database then emit an event (using an outbox or change data capture), with a separate process updating the index. Accept a few seconds of lag and have a mechanism to resync everything when needed.
A.Store every post in one table and sort at query time
B.Always push new posts into every follower's timeline
C.Always compute the timeline when the user opens the app
D.Fan out for ordinary accounts and compute at read time for large ones
Answer: D
Use a hybrid model: for normal accounts, push posts into followers' timelines immediately on publish; for accounts with very many followers, don't push, but merge them in when the user reads. This is how large social networks handle it.
What matters when scaling a system with hundreds of thousands of concurrent WebSocket connections?
A.WebSocket stops working past a certain number of connections
B.Connections are pinned to one machine, so an internal broadcast layer is needed
C.The connection count is limited by the server's TCP ports
D.Each connection needs its own process on the server
Answer: B
A connection is tied to a specific server, so to send a message to a user the system must know which machine they're on. The fix: an internal pub/sub layer so every machine receives the message and delivers it to the connections it holds.
B.Keep the failed or slow traces and sample the rest
C.Only sample at the outermost service and skip the inner ones
D.Sample a fixed proportion of every request at random
Answer: B
The common strategy is tail-based sampling: keep all traces of failed or high-latency requests, and keep a small percentage of normal traces as a baseline. The keep decision is made after the trace completes.
When should a system not be split into microservices?
A.When the system must handle very high traffic
B.When several teams work on one product
C.When the team is small and the business boundaries are not yet clear
D.When parts must be deployable independently of each other
Answer: C
Don't split when the team is still small and business boundaries aren't clear. Wrong boundaries create services that must change together — paying the full cost of a distributed system without gaining independent deploys.
What problem does consistent hashing solve when adding or removing nodes?
A.It speeds up key lookup within each node
B.It lets each key live on several nodes at once
C.Only a small fraction of the keys must move rather than all of them
D.It guarantees every node receives exactly the same number of keys
Answer: C
With modulo-based partitioning, changing the node count moves nearly every key. Consistent hashing places nodes and keys on a hash ring, so adding or removing a node only moves about 1/N of the keys — the rest stay in place.
In a replicated system, what does R + W > N guarantee?
A.Every node always holds identical data at every moment
B.Writes are always faster than reads
C.The read set and the write set always overlap
D.The system survives losing up to N nodes and keeps working
Answer: C
It guarantees that the read set and write set overlap: if a write needs W nodes to acknowledge and a read asks R nodes, with R + W > N there is always at least one node that both received the write and is queried — so the read sees the latest value.
Two nodes edit the same record during a partition. Which conflict resolution preserves the most data?
A.Reject both changes and report an error to the user
B.Keep the record with the newer timestamp
C.A data structure that merges both changes itself
D.Keep the record from the node with the larger identifier
Answer: C
Conflict-free replicated data types (CRDTs) let you merge both changes without losing either, since every application order yields the same result. The simpler "keep the newer version" approach always sacrifices one side and depends on clocks across machines.
A.Wait for the partner's response before returning to the user
B.Retry with backoff, sign the messages, and keep a delivery history
C.Deliver exactly once and never resend
D.Send sequentially in the exact order the events occurred
Answer: B
Three minimums: retry with backoff when the partner endpoint fails; sign messages so the partner can verify the source; and store delivery history for lookup during disputes. Alongside that, a mechanism to pause long-broken endpoints so resources are not wasted.
What is the central problem in a multi-channel notification system?
A.Choosing the cheapest channel for each notification
B.Storing every notification's content forever
C.Avoiding duplicates and respecting the user's preferences
D.Guaranteeing the notification arrives within one second
Answer: C
Two central problems: deduplication (the same event is not sent twice, and related events should be coalesced) and respecting user preferences per notification type and per channel. Sending too much is the fastest way to make users turn off all notifications.
Which metric should drive worker autoscaling for a queue-based system?
A.The queue depth or the age of the oldest message
B.The free memory on each worker
C.The number of user requests reaching the system
D.The workers' average CPU usage
Answer: A
Use queue depth or the age of the oldest message. These two metrics show whether workers are keeping up, while CPU can be very low if workers mostly wait on responses from other services.
What is the trade-off between batch and stream processing?
A.Batch only works on historical data
B.Streaming is more accurate because it handles each record
C.Streaming needs no raw data storage
D.Batch is simpler and cheaper, streaming gives results sooner
Answer: D
Batch is simpler, easier to reprocess when logic changes, and cheaper at large volumes. Streaming returns results in seconds instead of hours, at the cost of handling state, time windows, and late-arriving data — things that make the system considerably more complex.
Storing years of time-series data — what keeps storage under control?
A.Move everything to cold storage after a month
B.Only store a value when it differs from the previous one
C.Compress everything with a stronger algorithm
D.Reduce the resolution with age and delete what is too old
Answer: D
Use age-based downsampling: keep per-second data for a few days, roll it up to per-minute for a few months, per-hour for a few years, then delete. Combine this with time-based partitioning so deleting old data is just dropping a partition.
One customer sends huge traffic and slows everyone else. How is this handled?
A.Move that customer onto a separate system
B.Set per-customer quotas and isolate the resources
C.Ask that customer to reduce their call rate
D.Scale the system to serve the highest observed load
Answer: B
Set per-customer rate limits at the gateway and resource isolation for heavy operations. This is the noisy neighbor problem, and the real fix is making sure no one can consume more than their allocated share.
D.When reads have been measured to be the bottleneck
Answer: D
Only when measurements show read queries are the bottleneck and cheaper options have been tried: adding indexes, rewriting queries, adding cache. Denormalization trades this for write cost and the risk of data diverging between copies.
What should drive the choice of database type for a new feature?
A.The newest technology in that field
B.The real query patterns and the consistency requirements
C.That technology's maximum scalability
D.Whichever database the team knows best
Answer: B
Two main criteria: the query pattern (key lookups, range reads, full-text search, aggregation) and the business's consistency requirements. Only then come practical factors: whether the team has operational experience, and what the current system already has.
Where should user image processing (resizing, format conversion) happen?
A.Let the browser scale it down for display
B.Generate every size at upload time for every case
C.Process asynchronously, or generate on demand and cache
D.Process it synchronously in the upload request
Answer: C
Both approaches are valid: asynchronous processing after upload (an event triggers a worker to create the needed sizes), or on-demand generation on first request then cached at the CDN. The important thing is not to process images inside the user's own request.
What technique serves video across devices and network speeds?
A.Serve the original file and let the browser handle it
B.Split into short segments at several quality levels and let the client choose
C.Encode the video at the lowest quality so every network can play it
D.Download the whole video before playback starts
Answer: B
Use adaptive bitrate streaming: video is encoded at multiple quality levels and split into segments of a few seconds; the client measures network speed and picks a suitable level for each segment. This keeps video playing smoothly as the network changes.
A job system has urgent and routine work. How should it be organized?
A.Separate queues by priority with separately allocated workers
B.Add more workers so everything is processed quickly
C.One queue, reordered by priority when items are taken
D.Process everything in the order it entered the queue
Answer: A
Use separate queues per priority level, each with its own allocated workers. This ensures urgent work doesn't queue behind thousands of routine jobs, and a backlog in one type of work doesn't consume all the capacity of another.
How should pagination work for a continuously changing list?
A.Snapshot the data at the start and keep it for the whole session
B.Load the entire list and paginate on the client
C.Ordinary page number and rows per page
D.A cursor based on the last row's value, with a tie-breaking key
Answer: D
Use a value-based cursor: the next page takes records with values smaller than the last row of the previous page, plus a tie-breaker column so the order is always deterministic. This doesn't shift when new records are inserted between page flips.
Enabling a feature for 10% of users requires what bucketing mechanism?
A.Hash the identifier so each person always lands in the same group
B.Generate a random number per request and compare against a threshold
C.Enable it on 10% of the servers in the cluster
D.Enable it for the 10% of users who log in earliest each day
Answer: A
Hash the user identifier together with the feature name, then take the remainder to assign buckets. This gives a deterministic result: the same user always lands in the same bucket across every request and device, and different features bucket independently.
A user updates data, reloads, and sees the old value. What is the architectural cause?
A.The read went to a replica that has not yet received the write
B.The browser does not send a new request on reload
C.The write transaction has not been committed on the primary
D.The database does not support a strong enough isolation level
Answer: A
This is a read-your-writes problem: the write goes to the primary, but the next read hits a replica that hasn't received the change. Application-layer cache or a CDN can produce the same effect.
