Section 1: The Easiest Word in the Prompt - Problem Understanding & Clarifications

Executive Summary: This section covers the opening minutes of a Staff/Principal interview on a prompt that sounds almost too small to be a design problem: generate unique IDs. We look at why interviewers ask it, the two opposite ways candidates fail it, and how to break the sentence into what, who, why and how. Then we run a short clarification exchange where every answer removes something from the design or adds something to it. By the end you'll have a written list of assumptions, a running example, and the insight that drives the rest of the module: uniqueness alone is cheap. Uniqueness that fits in 64 bits and sorts by time, at a million IDs a second across five regions, is the real problem.

The interviewer reads you one sentence:

"Design a service that generates unique IDs for a large distributed system. Every team in the company (posts, messages, orders, payments) needs IDs for new records, at very high rates, in several regions."

It sounds like a warm-up. There's no feed to rank, no media to store, no user-facing screen. That's exactly why it's asked. With so little surface area, there's nowhere to hide: every decision comes down to a handful of bits, a clock, and the question "can two of these ever be the same?" A memorized acronym runs out in three minutes; reasoning from constraints fills the hour.

Candidates fail this prompt in two opposite ways:

Key Insight: Both failures skip the same step: finding out what "unique" has to mean here. The Recital picks a scheme before learning the constraints. The Citadel builds for a guarantee (strict global order) that the business never asked for. The interview is won in the questions.

Decomposing the Sentence

Before asking anything, map the territory out loud. Thirty seconds of this fixes the scope you and the interviewer share.

• What it does: One verb, mint. Hand back a number that has never been handed out before and never will be. A second, quieter verb is useful for operators: decode, meaning "tell me when and where this ID was made."
• Who calls it: Not humans. Every service team's code calls it: the posts service, the messaging service, order and payment systems. Callers are machines on the write path, so the call is made once for every record the company creates. Any latency we add is added to every write in the company.
• Why they need it: IDs become primary keys in databases, shard keys that decide where a row lives, a sort key ("show the newest messages first"), and dedup keys that let a retried request be recognized as the same request.
• How it's used: Inline, synchronously, on the hot path. A user taps Send, the messaging service needs an ID before it can write the row, and the user is waiting for the tick mark.

That last arrow is the important one. If IDs were only ever compared for equality, any unique value would do. But they're sorted, indexed and used to route data, so the shape of the ID (its width, its order) is part of the requirement.