Soms ontstaat technische schuld niet door een blunder, maar door een verstandige beslissing die te vroeg is genomen. Dit is wat Wise opnieuw onder de aandacht heeft gebracht nadat co-founder en CEO Kristo Käärmann op X liet weten dat het bedrijf bijna zijn 32-bits naamruimte voor transfer-ID’s heeft bereikt, een limiet die ze destijds hebben gekozen toen ze in 2010 de eerste regels code schreven.
Dit verhaal heeft iets van een interne grap onder ingenieurs en tegelijk een klassieke les in software-architectuur. Een ondertekend 32-bits geheel getal laat maximaal 2.147.483.647 positieve waarden toe. Een 64-bits ondertekend geheel getal verhoogt dat maximum naar 9.223.372.036.854.775.807. Op papier is het verschil enorm. In de praktijk was het 16 jaar geleden bijna onmogelijk voor te stellen dat een fintech ooit zo dichtbij het plafond zou komen.
Wanneer snel groeien een slechte keuze in de spotlight zet
Käärmann vertelde het met ironie. Hij erkende dat het een korte-termijnbeslissing was om te kiezen voor int in plaats van long, en grapte dat zijn ingenieurs misschien niet genoeg waarde hechten aan de vermeende besparing van 17 dollar op opslagkosten over de jaren heen. Buiten de grap samenvattend, illustreert dat commentaar heel goed hoe echte technische schuld werkt: een kleine, bijna onzichtbare beslissing in de beginfase van een project kan vele jaren later uitmonden in een schaalprobleem.
Wat het interessante van deze situatie maakt, is dat Wise niet een startup is die door slecht ontwerp van haar database in de problemen is gekomen. Integendeel, Wise heeft dit punt bereikt omdat het zo gegroeid is dat het volume meer is dan de meeste bedrijven ooit bereiken. In het fiscale jaar 2025 rapporteerde het bedrijf 15,6 miljoen actieve klanten en meer dan 145.200 miljard pond aan overzeese transactievolume. Het probleem met de ID’s klinkt dus niet als een dramatische fout, maar als een logische consequentie van exponentiële groei die de eerste jaren van de oprichters misschien niet hadden voorzien.
De database herinnert alles
In softwareontwikkeling lijken sommige beslissingen triviaal in de beginfase: het gegevenstype van een kolom, het formaat van een primaire sleutel, de lengte van een veld, de manier waarop een toestand wordt gemodelleerd, de initiële structuur van een tabel. In die vroege fase lijkt alles nog te passen en te kunnen worden aangepast. Maar wanneer dat ontwerp van enkele duizenden naar honderden miljoenen of zelfs miljarden rijen gaat, wordt dat heel anders.
Het kiezen voor een 32-bit geheel getal voor sequentiële IDs was jarenlang heel gebruikelijk. In veel zakelijke toepassingen was het voldoende. Maar bij een groeiend bedrijf zoals Wise wordt de theorie aangevuld met de schaal. Wanneer een platform jaren lang identificatoren koppelt aan echte bedrijfsactiviteiten, is het aanpassen van die velden geen eenvoudige schema-wijziging meer. Het raakt tabellen, indexen, API’s, reconciliatieprocessen, analytische tools, legacy-systemen en vaak ook externe integraties.
Daarom is dit soort incidenten zo leerzaam. Een database vergeet nooit. Een regel code die bij de start van het project werd geschreven, kan tientallen jaren blijven voortbestaan, verscholen onder lagen van extra functionaliteit, groei en internationale uitbreiding, totdat het plots een knelpunt wordt.
Geen eerste waarschuwing in de geschiedenis van software
Dit voorval doet denken aan andere technische perspectieffouten uit de geschiedenis, zoals het beperkt jaarformaat in legacy systemen uit de jaren 80 en 90, of beslissingen over adressering, capaciteit of formaat die in hun tijd efficiënt leken, maar uiteindelijk te klein bleken te zijn.
Het verschil is dat hier geen directe crisis zichtbaar is voor de klant. Er is geen dienstonderbreking of ernstig operationeel incident. Wat wel naar voren komt, is dat Wise een punt heeft bereikt waarop de eerste ontwerpkeuzes op grote schaal merkbaar worden. En dat is, binnen de context, een heel positief teken voor een softwarebedrijf.
Het laat ook zien hoe echte technologische producten worden opgebouwd. Architecturale perfectie bestaat bijna nooit vanaf dag één. Founders maken compromissen. Ze prioriteren het snel op de markt komen, een bedrijfsmodel valideren, een product aan klanten geven en het meest urgente probleem oplossen met de beschikbare middelen. Pas later, als het bedrijf groeit, worden de gevolgen van die keuzes zichtbaar en moet er worden ingegrepen.
Lessen voor nieuwe startups
De boodschap is niet dat elke startup vanaf dag één moet ontwerpen alsof ze honderden miljarden transacties zullen verwerken. Dat zou onrealistisch en vaak contraproductief zijn. Te vroeg overdetailleren kost tijd, complexiteit en geld.
De waardevolle lesson is daarentegen dat sommige structurele beslissingen beter met een bredere blik worden genomen. Het kiezen voor een 64-bits ID in een moderne database kost doorgaans geen enorme investering voor een startup, maar kan een migratierisico op lange termijn voorkomen. Denk aan schema’s voor partitionering, versiestrategieën of sleutelmodellen.
Wise heeft nog niet publiekelijk aangekondigd hoe ze dit limiet gaan oplossen, maar de industrie kent verschillende gangbare oplossingen: uitbreiden naar grotere datatypes, migreren naar bigint, nieuwe sequenties introduceren of het herontwerpen van de ID-generatie zonder compatibiliteit te verliezen. Geen van deze opties is eenvoudig, zeker niet wanneer het systeem al in productie draait met daadwerkelijke transacties.
Een bijna bewonderenswaardige technische schuld
Er is nog een laatste interpretatie, wellicht de gezondere. In een sector waarin “technische schuld” vaak wordt geassocieerd met onbetrouwbaarheid, slechte praktijken of improvisatie, vertegenwoordigt Wise een bijna bewonderenswaardige variant: technische schuld ontstaan door enorme groei.
Het is niet niets dat de oprichter van een bedrijf terug kan kijken op een beslissing uit 2010 en met humor kan toegeven dat die kortzichtig was. En nog minder dat die beslissing nu pas problemen oplevert omdat het bedrijf zo gigantisch is geworden. Veel technologieën worden ontworpen met de korte termijn in gedachten. Alleen weinigen hebben de langetermijnvisie om de impact van vroege keuzes zo lang later nog te kunnen erkennen.
Veelgestelde vragen
Hoeveel waarden kan een ondertekend 32-bits geheel getal voor IDs bevatten?
Het laat maximaal 2.147.483.647 positieve waarden toe, standaard voor een 32-bits ondertekend getal.
Waarom hebben ze niet meteen 64 bits gebruikt in Wise?
Kristo Käärmann erkende dat het een korte-termijnbeslissing was uit 2010, destijds genomen tijdens de eerste codestappen.
Is het ernstig dat Wise bijna het limiet van haar IDs bereikt?
Het is een belangrijke technische kwestie, maar geen catastrofe. Het laat vooral zien dat het bedrijf groeit en dat er een oude structurele keuze moet worden aangepast.
Welke oplossingen worden tegenwoordig meestal toegepast om dit te voorkomen?
De meest gebruikelijke aanpak is het gebruik van 64-bits integers (bigint) voor grote identificatoren, of het ontwikkelen van alternatieve generatiesystemen afhankelijk van de behoeften.