system design

The classic napkin-math question. The number in the prompt is the question, and candidates who draw the architecture before doing the arithmetic design something the physics forbids.

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.

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.

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.

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.