La deuda técnica no siempre nace de una mala práctica evidente ni de una chapuza de última hora. A veces aparece por una decisión perfectamente comprensible tomada al principio de un proyecto, cuando nadie imagina de verdad hasta dónde puede crecer el sistema. Eso es lo que ha vuelto a recordar Wise después de que su cofundador y CEO, Kristo Käärmann, reconociera públicamente que la compañía está a punto de agotar el espacio de 32 bits usado para los identificadores de transferencias, una elección que tomó en 2010 al escribir las primeras líneas de código.
El problema, explicado de forma simple, es este: un entero con signo de 32 bits permite hasta 2.147.483.647 valores positivos. Un entero con signo de 64 bits habría elevado ese techo a 9.223.372.036.854.775.807. Käärmann admitió en X que fue una decisión cortoplacista elegir int en lugar de long, y lo hizo con el humor que suelen reservarse los ingenieros cuando una decisión antigua vuelve a golpear muchos años después.
Lo interesante no es solo el detalle técnico. Lo relevante es que esto le ocurre a Wise porque ha alcanzado una escala enorme. En su ejercicio fiscal 2025, la compañía movió 145.200 millones de libras en pagos transfronterizos para 15,6 millones de personas y empresas. Es decir, no se trata de una base de datos mal diseñada en una startup que nunca maduró, sino de una plataforma que ha crecido tanto que ha terminado chocando con una decisión de modelado tomada cuando el proyecto apenas arrancaba.
Para administradores de sistemas y programadores, el caso es especialmente interesante porque toca una verdad incómoda: muchas veces el problema no está en la base de datos “de hoy”, sino en las suposiciones de “ayer”. Y esas suposiciones, cuando afectan a tipos de dato, claves primarias, secuencias, índices, particionado, foreign keys, replicación o contratos de API, no suelen romperse de golpe. Se convierten en una bomba lenta.
El error no fue usar INT: fue asumir que nunca se quedaría corto
Desde una perspectiva estrictamente técnica, usar INT para un identificador secuencial no era una locura en 2010. De hecho, durante años fue algo habitual en muchísimos sistemas. El problema aparece cuando ese tipo de dato pasa de ser un detalle interno a convertirse en una restricción global del sistema.
En una fintech como Wise, un ID de transferencia no suele vivir solo en una tabla. Puede aparecer en claves foráneas, colas, logs, pipelines ETL, herramientas de soporte, data warehouses, sistemas antifraude, auditorías, paneles internos, exports, documentación de APIs e integraciones con terceros. Cambiarlo no es un ALTER TABLE sin más. Es un proyecto de migración.
Ahí está la parte que más interesa a sysadmins, SREs y desarrolladores backend: el coste real de estas decisiones no está en los cuatro bytes de diferencia entre un INT y un BIGINT. Está en la complejidad de migrar un identificador central cuando el negocio ya depende de él en docenas de capas distintas.
En un sistema moderno, una migración de este tipo obliga a pensar en:
- compatibilidad hacia atrás en APIs y clientes;
- dual-write o columnas espejo durante la transición;
- backfill online sin degradar producción;
- impacto sobre índices y almacenamiento;
- cambios en particionado o sharding si existen;
- validación en replicas, backups y restauraciones;
- observabilidad para detectar lecturas o escrituras antiguas;
- y coordinación entre aplicaciones, equipos y ventanas de despliegue.
Es decir, el drama no es que un INT se quede pequeño. El drama es todo lo que ese INT ya ha contaminado a lo largo de 16 años.
La deuda técnica famosa casi siempre parece razonable al principio
El caso de Wise encaja muy bien con otros episodios clásicos de deuda técnica o decisiones de software que parecían sensatas cuando se tomaron y acabaron costando carísimo después.
El ejemplo más famoso sigue siendo el Y2K. Durante décadas, muchos sistemas almacenaron el año con dos dígitos para ahorrar espacio en memoria y almacenamiento. A corto plazo tenía sentido; a largo plazo se convirtió en una operación global de remediación para evitar errores masivos al cambiar del 99 al 00. NIST documentó en su momento cómo incluso los sistemas embebidos quedaban expuestos a este tipo de suposiciones históricas.
Otro caso icónico es el de Mars Climate Orbiter. El informe oficial de la NASA concluyó que la sonda se perdió por una discrepancia entre unidades imperiales y métricas en el software de navegación, un fallo que acabó destruyendo una misión valorada en 125 millones de dólares. Más que un bug aislado, fue una combinación de supuestos incompatibles entre equipos y software.
En el mundo financiero, Knight Capital ofrece otra lección muy conocida. La SEC explicó que el incidente de agosto de 2012 se debió, entre otras cosas, a dos errores tecnológicos críticos en el despliegue de software de su sistema de enrutamiento automatizado. El resultado fue una pérdida de más de 460 millones de dólares en menos de una hora. Aquí la deuda no era un tipo de dato, sino código antiguo y procesos de despliegue que no estaban bajo el control que una plataforma crítica exigía.
Y si se quiere ir al terreno más duro de todos, Therac-25 sigue siendo una referencia obligada. El caso se convirtió en un símbolo de lo que ocurre cuando software y procesos reemplazan salvaguardas físicas sin el nivel adecuado de revisión y seguridad. La Universidad de Texas resume el caso como uno de los ejemplos más graves de fallos de software en sistemas críticos, con seis muertes asociadas.
Todos estos casos tienen algo en común: no nacieron como “errores absurdos” para sus autores. Nacieron como atajos razonables, integraciones asumidas, decisiones de optimización o simplificaciones de contexto. Solo con el tiempo se convirtieron en problemas estructurales.
Lo que un sysadmin y un programador deberían leer entre líneas
La historia de Wise deja una enseñanza muy útil para equipos técnicos: hay decisiones que conviene sobredimensionar un poco desde el día uno, aunque el sistema todavía sea pequeño.
No se trata de diseñar una plataforma planetaria para una startup de tres personas. Se trata de reconocer qué piezas del sistema son especialmente caras de cambiar después. Los identificadores primarios, los formatos de tiempo, los contratos públicos, la semántica de estados, las claves de correlación, los esquemas de logs y las convenciones de particionado suelen entrar en esa categoría.
Dicho de otra manera: hay componentes que admiten improvisación y otros que no. Elegir mal una librería web puede molestar unos meses. Elegir mal el modelo de identidad de tus registros puede perseguirte una década y media.
Desde la óptica de infraestructura, además, este tipo de casos demuestra por qué la observabilidad y el inventario real de dependencias son tan importantes. Muchas organizaciones creen que “ya migrarán” cuando llegue el día, pero solo descubren la magnitud del problema cuando tienen que localizar dónde se usa realmente un identificador, en qué tablas, qué servicios aún esperan un INT, qué sistemas externos parsean ese valor y qué dashboards dejan de funcionar si cambia el formato.
La deuda técnica rara vez explota en la capa visible primero. Suele aparecer en las zonas menos glamurosas: jobs, exportaciones, scripts de soporte, integraciones heredadas, pipelines de datos, cachés y dashboards que nadie documentó del todo.
Comentario propuesto para David Carrero
Comentario propuesto para revisión editorial de David Carrero, cofundador de Stackscale:
“Casos como el de Wise recuerdan algo que en infraestructura vemos continuamente: casi ningún problema serio nace el día que falla, sino el día en que alguien asumió que un límite nunca se alcanzaría. En cloud y en sistemas distribuidos, el verdadero coste no suele estar en la decisión técnica original, sino en todo lo que se construye alrededor hasta convertirla en dependencia estructural.”
Ese comentario encaja especialmente bien en un medio para administradores de sistemas y programadores, porque pone el foco donde realmente duele: no en el tipo de dato en sí, sino en la acumulación de capas que dependen de él.
La buena noticia: esta es una deuda técnica de éxito
Conviene no perder la perspectiva. Que Wise esté cerca de agotar un espacio de 32 bits para IDs de transferencias no suena a tragedia empresarial. Suena, más bien, a una deuda técnica nacida del éxito.
Muchísimas empresas tecnológicas no llegan jamás al punto en el que una decisión tomada en su primer año se convierta en un problema real de escala 16 años después. Wise sí ha llegado. Y eso convierte el incidente en una historia útil para aprender, casi simpática en su origen, pero muy seria en su lección de fondo.
Porque el mensaje para cualquier equipo técnico es claro: las líneas de código más peligrosas no siempre son las más complejas. A veces son las más pequeñas. Las que nadie cuestiona. Las que se escriben en una tarde pensando que ya habrá tiempo de corregirlas más adelante.
Preguntas frecuentes
¿Por qué es un problema usar un entero de 32 bits para IDs?
Porque tiene un límite máximo de 2.147.483.647 valores positivos. En sistemas que generan muchísimos registros durante años, ese espacio puede agotarse.
¿No bastaba con usar un BIGINT desde el principio?
Sí, técnicamente habría dado muchísimo más margen. El problema es que muchas decisiones iniciales se toman con el contexto y las necesidades del momento, no con la escala que llegará una década después.
¿Qué complica tanto una migración de INT a BIGINT?
No suele afectar solo a una tabla. Puede impactar en índices, foreign keys, APIs, herramientas internas, integraciones externas, data lakes, logs, colas y sistemas heredados.
¿Es esto una mala noticia para Wise?
Técnicamente es un reto serio, pero estratégicamente refleja que la empresa ha alcanzado una escala enorme. Es una forma de deuda técnica que, en cierto modo, muchas compañías preferirían tener.
