A veces la deuda técnica no nace de una chapuza, sino de una decisión razonable tomada demasiado pronto. Eso es lo que ha vuelto a poner sobre la mesa Wise, después de que su cofundador y consejero delegado, Kristo Käärmann, admitiera en X que la compañía está cerca de agotar el espacio de nombres de 32 bits que eligió para los identificadores de transferencias cuando escribió las primeras líneas de código en 2010.
La anécdota tiene algo de broma interna entre ingenieros y algo de lección clásica de arquitectura de software. Un entero con signo de 32 bits permite hasta 2.147.483.647 valores positivos. Un entero con signo de 64 bits eleva esa cifra a 9.223.372.036.854.775.807. Sobre el papel, la diferencia es descomunal. En la práctica, hace 16 años era difícil imaginar que una fintech acabaría tan cerca de tocar ese techo.
Cuando crecer mucho convierte una mala elección en noticia
Käärmann lo contó con ironía. Reconoció que fue una decisión cortoplacista elegir int en lugar de long, y bromeó con que quizá sus ingenieros no valoran lo suficiente el supuesto ahorro de 17 dólares en almacenamiento a lo largo de los años. Más allá del chascarrillo, el comentario resume bastante bien cómo funciona la deuda técnica real: una decisión pequeña, casi invisible en el arranque de un proyecto, puede reaparecer muchos años después convertida en un problema de escala.
Lo interesante del caso es que no se trata de una startup que rompió por diseñar mal su base de datos. Al contrario. Wise llega a este punto porque ha crecido hasta un volumen que la mayoría de compañías nunca alcanzan. En su ejercicio fiscal 2025, la empresa informó de 15,6 millones de clientes activos y de 145.200 millones de libras en volumen transfronterizo procesado. Visto así, el problema de los identificadores no suena tanto a error dramático como a consecuencia lógica de haber escalado mucho más de lo que probablemente imaginaban sus fundadores en los primeros años.
La base de datos siempre recuerda
En desarrollo de software hay decisiones que parecen triviales cuando el producto apenas existe: el tipo de dato de una columna, el formato de una clave primaria, la longitud de un campo, la manera de modelar un estado o la estructura inicial de una tabla. En una fase muy temprana, todo eso parece reversible. El problema llega cuando ese diseño pasa de servir a miles de registros a soportar cientos de millones o miles de millones.
La elección de un entero de 32 bits para IDs secuenciales fue durante años una decisión perfectamente común. De hecho, durante mucho tiempo resultó suficiente para infinidad de aplicaciones empresariales. Lo que cambia en compañías como Wise no es tanto la teoría como la escala. Cuando una plataforma lleva años generando identificadores ligados a operaciones reales de negocio, modificar ese campo deja de ser un simple cambio de esquema: afecta a tablas, índices, APIs internas, procesos de conciliación, herramientas de análisis, sistemas heredados y, en muchos casos, integraciones externas.
Por eso este tipo de incidentes resulta tan pedagógico. La base de datos no olvida nunca. Una línea escrita al principio del proyecto puede permanecer en producción durante décadas, escondida bajo capas de producto, nuevas funcionalidades y crecimiento internacional, hasta que un día se convierte en un cuello de botella.
No es el primer aviso de la historia del software
El caso recuerda inevitablemente a otros errores de perspectiva tecnológica, desde el año almacenado con dos dígitos en los sistemas heredados de los años 80 y 90 hasta decisiones de direccionamiento, capacidad o formato que parecían eficientes en su momento y acabaron quedándose pequeñas.
La diferencia es que aquí no hay drama ni crisis visible para el cliente. No se ha presentado como una caída de servicio ni como una incidencia operativa grave. Lo que ha aflorado es una señal de madurez: Wise ha llegado al punto en el que sus primeras decisiones de ingeniería empiezan a notarse a escala masiva. Y eso, dentro de lo que cabe, es una muy buena noticia para una empresa de software.
También revela algo importante sobre cómo se construyen los productos tecnológicos reales. La perfección arquitectónica casi nunca existe en el día uno. Los equipos fundadores eligen compromisos. Priorizan salir al mercado, validar un modelo, poner un producto en manos de clientes y resolver el problema más urgente con los recursos del momento. Después, si la empresa sobrevive y crece, llega la factura de esas decisiones.
La lección para nuevas startups
El mensaje no debería ser que toda startup tiene que diseñar desde el principio como si fuera a gestionar miles de millones de operaciones. Eso sería poco realista y, a menudo, contraproducente. Sobrediseñar demasiado pronto también cuesta tiempo, complejidad y dinero.
La lección más útil es otra: algunas decisiones estructurales sí merecen una mirada un poco más larga. Elegir un identificador de 64 bits en una base de datos moderna rara vez va a arruinar el presupuesto de una startup, pero puede evitar una migración delicada años después. Lo mismo ocurre con ciertos esquemas de particionado, estrategias de versionado o modelos de claves.
Wise no ha contado públicamente en detalle cómo resolverá este límite, pero la industria conoce bien el tipo de salida habitual: ampliar tipos, migrar a bigint, introducir nuevas secuencias o rediseñar la generación de IDs sin romper compatibilidad. Ninguna de esas opciones es trivial cuando el sistema ya está en plena producción y mueve operaciones reales de dinero.
Una deuda técnica casi envidiable
Hay una última lectura, quizá la más sana de todas. En un sector acostumbrado a asociar “deuda técnica” con fragilidad, malas prácticas o decisiones improvisadas, lo de Wise representa una variante casi envidiable: la deuda técnica provocada por haber crecido muchísimo.
No es poca cosa que el fundador de una compañía pueda mirar una decisión tomada en 2010 y admitir, con humor, que fue miope. Menos todavía cuando esa decisión solo se convierte en problema porque la empresa ha alcanzado una escala gigantesca. Muchas tecnologías nacen pensando en el próximo trimestre. Muy pocas llegan a vivir lo suficiente como para que sus errores iniciales sigan ahí 16 años después.
Preguntas frecuentes
¿Cuántos valores permite un entero de 32 bits para IDs con signo?
Permite hasta 2.147.483.647 valores positivos, que es el límite habitual cuando se usa un entero con signo de 32 bits.
¿Por qué no usaron 64 bits desde el principio en Wise?
El propio Kristo Käärmann reconoció que fue una decisión cortoplacista tomada en 2010, cuando escribió las primeras líneas de código del sistema.
¿Es grave que Wise llegue al límite de sus IDs?
Es un problema técnico importante, pero no necesariamente una tragedia. En realidad refleja que la compañía ha alcanzado una escala enorme y que ahora debe corregir una decisión estructural antigua.
¿Qué alternativa suele usarse hoy para evitar este problema?
Lo más habitual es usar enteros de 64 bits (bigint o equivalentes) para claves secuenciales con gran proyección de crecimiento, o sistemas alternativos de generación de identificadores según el caso.
Now that we're soon running out of 32-bit namespace for transfer IDs at @Wise, the engineers are annoyed with me choosing int over long when I wrote the first lines of code in 2010.
— Kristo Käärmann (@kaarmann) April 15, 2026
But why don't they appreciate the $17 of savings in storage cost over years!? 🤷