When the Numbers Run Out

Successful systems often expose limits that looked comfortably large when they were designed.

In the late 1990s, during my time at Maplin, we encountered a deceptively simple problem: we ran out of barcode numbers for products.

The physical barcode had not failed. The scanners still worked. The tills still worked. The warehouse still worked. What had reached its limit was the identifier space behind the system.

Capacity limits are not confined to people, money or machinery. Even an identifier can run out.

Barcodes: from checkout aid to information infrastructure

The modern retail barcode was standardised in the United States in 1973, with the first commercial checkout scan taking place on 26 June 1974 at a Marsh supermarket in Ohio. A packet of Wrigley’s Juicy Fruit gum became the first product scanned using the UPC system.

Europe followed with the EAN system, designed to be compatible with UPC. Over time, what began as a way to speed checkout became part of a much wider information architecture linking suppliers, warehouses, catalogues, stock systems, tills and later websites.

That growth matters. A numbering scheme can appear generous when first designed, but if the organisation grows, the number of products grows, or the same identifier has to serve more systems, the available namespace can eventually become a constraint.

The hidden assumption

Running out of identifiers is not really a barcode problem. It is an architectural problem. Somewhere in the system sits an assumption:

“This number range will always be large enough.”

That assumption may be buried in databases, labels, software, catalogue systems and interfaces. Expanding the identifier range can therefore require more than simply printing a longer number. Every connected system must be able to store it, pass it, display it and interpret it correctly.

IPv4: the same problem at global scale

The internet encountered a remarkably similar problem. IPv4 uses a finite address space. As the internet expanded rapidly in the late 1980s and early 1990s, it became clear that the original allocation model would not scale indefinitely.

Engineers responded in stages. Classless Inter-Domain Routing (CIDR) made allocation more efficient. Network Address Translation (NAT) allowed many devices to share public IPv4 addresses. These measures extended the useful life of IPv4, but they did not remove the underlying capacity limit.

IPv6 was the architectural answer: a vastly larger address space designed for the scale the internet had become.

The engineering lesson

The barcode and IPv4 stories share a common pattern:

• a design assumption is reasonable at the beginning;
• the system succeeds and grows;
• growth consumes the available headroom;
• temporary workarounds postpone the constraint;
• eventually the architecture itself has to change.

A design limit can remain invisible for years precisely because the system has never yet reached it.

This is why headroom matters. Good systems are not designed only for today’s load. They consider growth, abnormal demand, future interfaces and the cost of changing assumptions later.

The public-sector equivalent

Public systems contain the same kinds of hidden limits: fixed-length reference numbers, old database fields, restricted category codes, legacy forms, hard-coded workflow assumptions and systems designed for volumes that no longer reflect reality.

When those limits are reached, the visible symptom may look administrative — a rejected form, a duplicated case, a missing record or an awkward workaround. The underlying cause may be much deeper: the architecture has reached a boundary its designers never expected to encounter.

Do not ask only whether the system works today. Ask what happens when it succeeds, grows and reaches the edge of its assumptions.

---

Sources and historical references

• GS1 historical timeline — UPC standardisation, first retail scan, EAN development and later barcode standards.
• IETF RFC 3789 — history of IPv4 scaling pressures and address-space exhaustion.
• IETF RFC 6269 — IPv4 address sharing and the long-term role of IPv6.
• IETF RFC 8200 — current IPv6 specification.

The Maplin example is a personal recollection and will be refined against surviving records if documentary evidence becomes available.