Step 3: Capacity Estimation

Every figure in this estimate is small except one: the request rate. That makes this a compute problem, not a storage problem. The diagram summarizes the numbers worked out below.

Request volume. A baseline of 100,000 ID requests per second is 8.6x10^9 IDs a day (100,000 x 86,400). Peaks of 200,000 to 300,000 per second give 1.7x10^10 to 2.6x10^10 a day, and a year's total reaches trillions.

ID size and format. A time-sortable ID is a 64-bit integer, 8 bytes, or up to 19 or 20 digits as a decimal string. An opaque ID is a 128-bit UUID, 16 bytes, usually written as a 36-character string with hyphens.

Both widths are more than enough. A 64-bit integer represents up to 9.22x10^18 values, while 10^10 IDs a day for 10 years is only 3.65x10^13. A 128-bit space, about 3.4x10^38 values, makes uniqueness by randomness practical. The sortable ID stays at 64 bits for a second reason: it fits a native integer type, so database indexes on it stay small and fast.

Data storage. The service computes each ID and returns it; it never records one. A table of issued IDs would take 100,000 inserts per second, would be the largest write workload in the system, and nothing would ever read it. Leaving it out costs nothing, because uniqueness comes from how an ID is built, not from checking a list.

The only persistent data is small metadata: the coordinator holds the machine numbers assigned to live nodes, and the segment mode in Step 6 would hold one counter per segment. Both are a few bytes per entry.

Memory. Each generator holds its last timestamp, its sequence counter, and its machine number, a few bytes in total. There is no cache and no stored data, so memory never grows with traffic, and even 1,000 instances need a trivial amount.

Coordinator load. A generator contacts the coordinator when it starts and then sends periodic heartbeats. A thousand nodes sending one every few seconds produce a few hundred small messages per second, a load any coordination cluster handles without tuning.

Network throughput. At about 50 bytes per response, including protocol overhead, 100,000 IDs per second is about 5 MB per second across the cluster, and 500,000 per second is about 25 MB per second.

Read/write ratio. The workload is almost entirely the creation of new IDs. Nothing reads an existing ID back from storage, and there are no multi-row transactions. A request to validate an ID's format, if the service offers one, is arithmetic on the bits rather than a lookup.

With a few bytes of data per node, modest network load, and nothing to read back, the rest of the design only has to answer one question: how to compute unique IDs quickly on many machines at once.