1. Distributed Unique IDs

Distributed unique ID generation is the problem of letting many independent processes mint identifiers that never collide, without routing every one of them through a single allocator. For most of a system's life it is not a problem at all: one database hands out auto-increment primary keys and the question never comes up. It becomes a decision the moment a second process can create a row, because two checkouts at the same instant on two machines have to end up with two different order IDs, and nothing is watching both of them.

In an interview this almost never arrives as its own question. It is usually a short detour after you sketch a data model and name a primary key, or after the interviewer adds a second service instance. A mid-level answer should explain that random IDs need no coordination while auto-increment does. A senior answer should also be able to sketch a bit layout, state its ordering guarantees, and handle clock skew and write-throughput constraints.

Reason about the decision in the same order it usually develops: establish the uniqueness requirement, choose a generation scheme, and then test where that scheme breaks.