Interview questions

Interview questions (with the counter-questions you'll get)

Q1. How would you generate unique IDs in a distributed system?

They're testing: knowing the options and their trade-offs.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It depends on what I need. UUIDs need no coordination; v7 adds time order, which is kinder to database indexes than random v4. Snowflake-style IDs pack a timestamp, a machine ID and a sequence into 64 bits, so they're compact, roughly time-ordered and generated locally, but need unique machine IDs and a well-behaved clock. Ticket servers handing out ranges keep small numeric IDs with a small coordination cost. A single database's auto-increment is fine while there's one database.
3
4**Counter-questions:**
5- *"Which would you pick for a chat app?"* → Snowflake-style or UUID v7: messages need time order and a very high write rate without a central counter.
6- *"What if IDs appear in public URLs?"* → Use a separate random public ID, and always check authorisation.
7
8**Trap:** naming one scheme as the answer without trade-offs.

Q2. Explain the Snowflake ID format.

They're testing: depth and numbers.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** 64 bits: one unused sign bit, 41 bits of milliseconds since a custom epoch (about 69.7 years), 10 bits of machine ID (1,024 generators), and 12 bits of sequence (4,096 IDs per millisecond per machine). IDs are unique because no two machines share a machine ID and each machine never repeats a sequence in the same millisecond. They sort roughly by time and fit in a BIGINT.
3
4**Counter-questions:**
5- *"What if a machine needs more than 4,096 IDs in a millisecond?"* → It waits for the next millisecond. If that's routinely a limit, give it more sequence bits and fewer machine bits, or run more generators.
6- *"How are machine IDs assigned?"* → From configuration, or leased from a coordinator like ZooKeeper or etcd at startup, so two live generators never share one.
7
8**Trap:** forgetting the machine bits, which are what make it unique across machines.

Q3. UUID v4 vs UUID v7?

They're testing: current knowledge and the index impact.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** v4 is 122 random bits: no information, unguessable, but random order, which scatters inserts across a B-tree index and slows writes on big tables. v7 starts with a 48-bit millisecond timestamp followed by random bits, so it sorts by creation time and inserts land near the end of the index, while keeping strong uniqueness. v7 reveals the creation time, which is usually fine.
3
4**Counter-questions:**
5- *"Is a v4 collision a real risk?"* → Not in practice: about 2.7 × 10¹⁸ IDs for a 50% chance. A bug in the random number generator is a far bigger risk.
6
7**Trap:** "UUIDs are slow" without explaining why.

Q4. Why not just use auto-increment everywhere?

They're testing: understanding where it breaks.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** It's great with one database. With several shards, each counts on its own and IDs clash; with one shared counter, every write depends on it and it becomes a bottleneck and a single point of failure. You also can't know the ID before inserting, and sequential IDs in public URLs invite enumeration. Step-and-offset or ranges can extend it, but you have to plan that.
3
4**Counter-questions:**
5- *"Can you keep auto-increment with shards?"* → Yes, with different offsets per shard and a step equal to the number of shards, but adding shards later is awkward.
6
7**Trap:** saying auto-increment is "bad".

Q5. How do clock problems affect time-based IDs?

They're testing: distributed-systems realism.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Clocks drift and get corrected, sometimes backwards. A Snowflake generator that resets its sequence when it sees a "new" millisecond can repeat an earlier millisecond and produce duplicates. Generators should remember the last timestamp and wait or refuse when the clock goes backwards. Also, IDs from different machines are only roughly ordered, so they shouldn't be used to decide exact event order across machines.
3
4**Counter-questions:**
5- *"How else can you reduce the risk?"* → Use time sync that slews instead of stepping, monitor clock offset, and alert on large corrections.
6
7**Trap:** assuming clocks only move forward.

Q6. How do ticket servers work?

They're testing: a practical coordinated approach.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A ticket server hands out IDs or blocks of IDs from a central counter, often a single database row updated atomically. App servers take a block, say 1,000 IDs, and use them locally, so the server is called rarely. To avoid a single point of failure, run two with step 2 and different offsets (odd and even), as Flickr described. IDs stay short and numeric but are only roughly time-ordered.
3
4**Counter-questions:**
5- *"What happens to unused IDs when an app server crashes?"* → They're skipped. Gaps are harmless; reuse would be dangerous.
6
7**Trap:** thinking every ID needs a call to the ticket server.

Q7. Should IDs in URLs be sequential?

They're testing: security awareness.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Not for anything private or where volume is sensitive. Sequential IDs let people enumerate resources and estimate business volume, and if any endpoint forgets an authorisation check, enumeration becomes a data leak. Authorisation must be checked regardless; for links that grant access by themselves, use long random tokens. A common pattern is an internal sequential key plus a public random ID.
3
4**Counter-questions:**
5- *"Isn't a UUID in the URL enough security?"* → It makes guessing impractical, but URLs leak through logs, browser history and sharing. It's defence in depth, not a replacement for checks.
6
7**Trap:** "use UUIDs so we don't need auth checks".

Q8. How would you generate IDs for a URL shortener?

They're testing: applying this to a classic design.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** A counter with blocks of IDs from a ticket server, encoded in base62: 7 characters give about 3.5 trillion codes. It never collides and needs no lookup before insert. To avoid guessable codes, scramble the counter with a one-to-one mapping before encoding, or use random codes with a uniqueness check if privacy matters (Chapter 31).
3
4**Counter-questions:**
5- *"Why not hash the URL?"* → Truncated hashes collide and need checking and retries, and identical URLs from different users would share a code.
6
7**Trap:** hashing and truncating without handling collisions.

Q9. How do Snowflake IDs help with sharding?

They're testing: connecting IDs to data layout.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** If the ID includes a shard ID, as in Instagram's scheme, any service can tell which shard holds a row just from its ID, with no lookup. Even without that, globally unique IDs mean rows can be moved between shards or merged without renumbering.
3
4**Counter-questions:**
5- *"What's the risk of putting the shard in the ID?"* → Moving a row to another shard means its ID points at the wrong place, so you need a mapping for moved rows or a scheme where logical shards map to physical servers (Chapter 15).
6
7**Trap:** not connecting IDs and sharding.

Q10. What size should IDs be: 32-bit, 64-bit or 128-bit?

They're testing: practical judgement.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** 32-bit integers run out at about 2.1 billion (signed), which real systems have hit, so I'd start with 64-bit for anything that may grow. 64-bit fits Snowflake-style IDs and is compact in indexes. 128-bit UUIDs are larger but need no coordination at all. I'd avoid storing UUIDs as 36-character strings; store them in a native UUID or 16-byte binary type.
3
4**Counter-questions:**
5- *"What happens when a 32-bit ID runs out?"* → Inserts fail; migrating a huge table's key to 64-bit is slow and risky, so plan ahead.
6
7**Trap:** not knowing the 32-bit limit.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 10.1 A good ID | Level 1A, Q1, Q10 |
18| 10.2 Auto-increment | Level 1A.1, Level 1B.3, Level 5.5, Q4 |
19| 10.3 Why it breaks | Level 1A.5, Q4 |
20| 10.4 UUIDs | Level 2.4, Level 3.3, Q3 |
21| 10.5 Snowflake | Level 2.1, Level 2.2, Level 3, Level 5.1, Q2, Q9 |
22| 10.6 Ticket servers | Level 1A.4, Q6, Q8 |
23| 10.7 Clock skew | Level 1B.2, Level 4, Level 5.3, Q5 |
24| 10.8 Base62 | Level 2.3, Q8 |
25| 10.9 Guessable or not | Level 1A.3, Level 1B.1, Level 5.4, Q7 |
26
27---

10. Unique ID Generation