DevOps System Design Interview Questions

Stateless does not mean there is no state. It means the state is not in the instance, which is what lets you kill any instance at any time. Every scaling and deployment property people want depends on that one thing.

It converts a synchronous failure into a delay. That is the whole benefit and the whole cost, because the caller now gets an answer before the work has happened and somebody has to tell them when it did.

The classic napkin-math question. The number in the prompt is the question. Drawing the architecture before doing the arithmetic produces a design the physics forbids, and the arithmetic takes a minute.

The design round where the honest answer is mostly about data. Stateless traffic across regions is straightforward; the database is where active-active is either solved or pretended.

The migration question, and the trap is answering with a target architecture. What is being scored is sequencing: how you get there without a rewrite and without a release freeze.

The Indian e-commerce interview question, and autoscaling is the wrong first answer. A 10x spike arriving in seconds outruns any scaling loop, so the design has to absorb rather than scale.

Every candidate says replication and failover. The scoring answer names the replication mode, states the resulting data loss window, and explains how the cluster avoids two primaries.

The Google-style NALSD round in miniature. The boxes are easy; what is being scored is whether the numbers fall out of Little's law before you draw them.

The default answer is 'horizontal' because interviews reward it. The correct answer names the constraint that makes distribution expensive and knows when one big machine is the engineering choice.

Everyone names token bucket. The scored part is the rest: drift between nodes, the 429 contract with clients, and whether your quota service should fail open or closed.

The catalog is the easy half. The scored half is stampede dynamics: one hot key expiring can multiply origin load by a thousand in a second, and there are three distinct fixes.

Cron is the most-deployed scheduler on earth and the worst-behaved at scale. The scored content is everything crontab cannot do: exactly-once firing, thundering herds, and what happens when the scheduler itself dies.

CAP is not a menu of two letters per system. The scored answer knows what the theorem claims (narrowly), what most engineers misquote, and what a split-brain costs when both halves accept writes.

Timeouts guarantee uncertainty, not failure: the first request may have succeeded after the client gave up. The idempotency key pattern is the industry answer; the scored details are storage, expiry and concurrency.

The most rehearsed design question, which is exactly why the interesting parts are the ones blog posts skip: redirect semantics, key generation under failure, and analytics kept off the hot path.

Outbound delivery looks like a queue and a loop until one subscriber hangs for sixty seconds and takes your workers with it. Isolation, retry horizons, and signatures are where the marks are.

The vocabulary question hiding real depth: which primitive replaces ORDER BY, why sharding by player is wrong, and what a 45,000 updates-per-second storm actually costs.

Two contracts in one system: an OTP with a 30-second promise and a sale announcement reaching fifty million phones without burning providers. Priority lanes and double-layer dedup decide the grade.

Flags sit on the request path of everything, so a slow flag service is a site-wide outage waiting to happen. Local snapshots, propagation numbers and audit trails are where this design is decided, because they determine what happens when the flag service itself is unavailable.

Sharding buys write headroom and bills you in joins, foreign keys, and every future migration. The key choice is a query-pattern bet; the resharding choreography separates operators from diagram artists.

Type-ahead is a latency budget wearing a search costume: keystrokes arrive every 200 milliseconds, so anything slower feels broken. Prefix indexes, freshness tiers, and typo tolerance are the scored parts.

Every overloaded system dies the same way: queues turn load into latency, latency into timeouts, timeouts into retry storms. Tiered shedding, deadline propagation, and retry budgets are the design.

Everyone sizes a metrics system by samples per second and everyone is wrong. The constraint that actually kills these platforms is a single label added on a Friday.

Size stored sessions from expiry and creation rates, then decide how quickly logout must take effect and what failover may forget.

Never-delete is a policy, not a control. Auditors and attackers both want to know what stops an admin with broad credentials, and the answer has to be mechanical.

The app server that proxies uploads through itself is the design that fails this question. Direct-to-storage, validate after arrival, and make CDN invalidation almost never necessary.

Dual-writing from application code is the answer that fails quietly six months in. Change data capture, per-entity ordering, and a reindex you could run on a Tuesday are what interviewers score.

The difficult decisions are preserving offline intent and enforcing rules that span devices. Name the conflict classes and handle each deliberately rather than proposing a CRDT framework on instinct, because most of these conflicts have a domain answer that no merge algorithm can supply.

Leases prevent dead holders but not overlapping ones. The staff-level answer is fencing tokens and a candid account of why quorum lock services without downstream checks are still probabilistic.

This is a machine identity problem wearing a secrets costume. Candidates who start at encryption miss that authentication of the caller and delivery mechanics are the real design space.

Listing the match job is table stakes. The scored material is the breaks taxonomy, the suspense account, and why every match must be replayable from immutable raw files.

Every candidate lists the three isolation models. The offer-worthy answer prices them per tenant, does the migration fan-out arithmetic, and lands on a hybrid with reversal conditions.

Drawing an agent that polls a server is the easy third. The interview is about partial applies, fleet-versus-world state, and why rollback must be a pointer flip, never a reverse edit.

Ladders and player logic are the warm-up. Cache topology, egress arithmetic, and knowing which quality metric actually predicts churn are what separate the answers.

This is a platform-organization question disguised as infrastructure. Score comes from separating enforcement from ownership and explaining what stops the gateway becoming a smart ESB.

Trace a retry through the broker, database and external provider. The guarantee changes at each boundary, and a recorded intent does not prove a payment or email completed.

Vendor limits are a shared budget your own teams will fight over. Broker the capacity, degrade by priority lane, and never let feature code see vendor HTTP semantics.

Reciting both acronyms is the median answer. Expert level chooses by connectivity assumptions and undo semantics, then defends CRDT metadata growth with numbers.

A disputed invoice needs a reproducible calculation. Retain raw usage events and versioned pricing so each line can be explained and corrected.

Cron fires at wall-clock times; a scheduler reasons about data intervals and blocked frontiers. The scored details are per-partition idempotency and catch-up semantics.

Teams need comparable evaluations before they approve a model change. Design versioned test data, recorded runs and release thresholds that a pipeline can enforce.

The hard parts are not search. They are deciding what to keep before you pay to store it, isolating one team's query from everyone else's, and making the cost visible to the people generating it.

Without one, every team implements its own retries, its own key handling, its own logging policy, and nobody can answer what the company spends or what a model change would break.

Queue time and build time are separate problems with separate fixes, and most teams spend a quarter optimising the one that is not hurting. Size the fleet from arrival rate, then attack the build with caching and graph awareness.

Comparing the canary against last week is how a Tuesday afternoon looks like a regression. Compare it against a baseline running the same traffic at the same moment, and decide with a threshold somebody can defend.

Most migrations are safe and a handful can take the site down by holding a lock for eight seconds. Build the tooling to tell those apart automatically, because a review culture cannot do it two hundred times a month.

A catalogue nobody updates is worse than no catalogue, because people trust it once and get burned. Derive everything you can from systems that are already true, and make the rest a gate rather than a request.

The auditor does not require a meeting, they require evidence that changes are authorised, tested and reversible. Generate that evidence from the pipeline and the board stops being the bottleneck.

Build once and move the same bytes. The moment an environment rebuilds from source, you are testing something that has never run anywhere, and no amount of pipeline output can tell you what production holds.

Turning on strict mTLS across two hundred services in one change breaks everything that talks to something outside the mesh. Permissive mode exists so the migration can be observed instead of guessed at.

DNS time-to-live is a suggestion and nineteen minutes is what believing it costs. The mechanism you choose decides your failover time, and the health check you choose decides whether it fires at all.

Erasure is a distributed transaction across systems that were never designed to participate in one, and backups make a literal delete impossible. The design that works is a deletion ledger plus crypto-shredding, not a fan-out of delete statements.

An untested backup is a belief, not a control. The design that matters is the one that restores automatically on a schedule and verifies the result, because that is the only thing that produces a recovery time you can quote.

A single FIFO queue is a first-come-first-served promise to whoever submits fastest. Fairness needs per-tenant queues and a scheduler that picks between them, and priority without fairness just moves the problem.

A published event is an API with no version negotiation and consumers you cannot enumerate. The design is a registry that refuses an incompatible change at publish time, because after publication your options are all bad.