El error de $8M que Uber prefirió olvidar
Uber migró más de 1 billón de registros financieros y ahorró $6 millones anuales — todo por haber elegido mal su base de datos en 2017. Lo más revelador no es el costo: es que nadie fue despedido por esa decisión.
El caso, analizado en detalle por Álvaro Durán en su newsletter sobre sistemas de pagos, expone uno de los errores más costosos y silenciados en la arquitectura fintech moderna. Y las lecciones aplican directamente a cualquier startup que hoy esté construyendo un sistema de pagos sobre infraestructura cloud.
¿Qué hizo mal Uber con DynamoDB?
En 2017, Uber lanzó Gulfstream, su plataforma de pagos interna, y eligió DynamoDB de AWS como el almacén principal para su sistema contable (ledger). La decisión tenía sentido en papel: DynamoDB ofrece alta disponibilidad, escalabilidad horizontal y latencias bajas para escrituras.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidadEl problema es que un ledger financiero no es una base de datos operacional cualquiera. Es un registro append-only — se escribe una vez y se lee muchas — que crece de forma indefinida sin compresión natural. Y DynamoDB cobra por gigabyte almacenado más las unidades de lectura y escritura, lo que en el contexto de millones de transacciones diarias se vuelve insostenible.
Con el tiempo, Uber procesaba más de 30 millones de transacciones por día. Los costos de almacenamiento se dispararon. La solución temporal fue dividir los datos en dos capas:
- Datos «calientes» (hot): las últimas 12 semanas en DynamoDB.
- Datos «fríos» (cold): todo lo anterior en TerraBlob, el sistema de almacenamiento interno similar a S3.
Esto redujo costos momentáneamente, pero introdujo complejidad operativa severa: escrituras dobles, consultas entre sistemas, y riesgos de corrupción al manejar billones de registros.
¿Por qué DynamoDB es una mala elección para sistemas contables?
No se trata de que DynamoDB sea una mala tecnología — es excelente para su caso de uso. El problema es aplicarla donde no encaja. Un ledger financiero requiere:
- Consistencia fuerte (ACID): DynamoDB ofrece consistencia eventual por defecto. La consistencia fuerte es más cara y más lenta, y en sistemas financieros no es opcional.
- Integridad garantizada: Los sistemas contables necesitan doble entrada, auditoría inmutable y capacidad de reindexar sin perder datos. DynamoDB no tiene características nativas de ledger.
- Almacenamiento económico para datos históricos: Los ledgers crecen para siempre. DynamoDB no tiene una solución nativa de archivado barato — hay que construirla encima.
La alternativa que terminó construyendo Uber fue LedgerStore, un sistema propio con commits de dos fases (2PC) para índices fuertes, vistas materializadas para los eventuales, y una arquitectura pensada específicamente para datos contables inmutables.
La migración: 1 billón de registros sin apagar el sistema
Migrar de DynamoDB a LedgerStore no fue trivial. Uber tardó tres meses en completar el proceso, que incluyó:
- Replicación de 1 billón de registros usando Apache Spark para los backfills.
- Escrituras en paralelo (dual writes) durante la transición para garantizar consistencia.
- Validación por sombra (shadow validation) para detectar discrepancias antes de cortar el tráfico.
- Rate limiting para no saturar los sistemas origen durante la migración.
- Fallback a DynamoDB como medida de seguridad si algo fallaba.
El resultado: sin tiempo de inactividad y un ahorro de más de $6 millones anuales a partir de entonces. El costo acumulado de haber usado DynamoDB de forma inapropiada durante años se estima en torno a los $8 millones.
El incentivo perverso detrás de la decisión
Aquí está la parte más incómoda del análisis de Durán: nadie fue despedido. Y eso no es un accidente.
El problema no fue técnico en origen — fue de incentivos. En equipos de ingeniería de alto crecimiento, la presión por velocidad de entrega supera casi siempre a la reflexión sobre costos operativos a largo plazo. DynamoDB era familiar, estaba disponible, y funcionó en producción desde el primer día. La factura no llegó hasta años después, cuando el equipo original ya había rotado.
Este patrón tiene un nombre en el mundo de la gestión tecnológica: «nobody gets fired for buying IBM» — la tendencia a elegir lo «obvio» o lo «que todo el mundo usa» para protegerse políticamente, aunque no sea la mejor opción técnica o económica.
Para una startup, este riesgo es mucho más grave. Uber pudo absorber $8 millones en costos mal gestionados. La mayoría de las startups no pueden.
¿Qué significa esto para tu startup?
Si estás construyendo o planeas construir un sistema de pagos o cualquier infraestructura financiera, estas son las decisiones que pueden costarte millones más adelante:
1. Evalúa el modelo de costos de tu base de datos antes de escalar
DynamoDB, Firestore, Cosmos DB y otras bases de datos NoSQL gestionadas en cloud tienen modelos de precios basados en operaciones y almacenamiento. Funcionan muy bien en etapas tempranas. A escala de millones de transacciones mensuales, el modelo de costos cambia drásticamente.
- Estima el crecimiento de tus datos a 12, 24 y 36 meses.
- Simula el costo mensual usando las calculadoras de AWS, GCP o Azure con esas proyecciones.
- Compara contra alternativas como PostgreSQL (gestionado en RDS o Supabase), CockroachDB o PlanetScale.
2. Diseña con separación hot/cold desde el inicio
No esperes a que los costos exploten. Si tu sistema financiero va a almacenar datos históricos que raramente se consultan, define desde el principio una política de archivado: qué datos se quedan en la base de datos principal y cuáles pasan a almacenamiento barato (S3, GCS, Azure Blob).
- Define el umbral de «datos calientes» (típicamente 30–90 días según el caso de uso).
- Automatiza el archivado con jobs nocturnos o triggers basados en edad del registro.
- Asegúrate de que los datos fríos siguen siendo consultables para auditorías y cumplimiento.
3. No elijas NoSQL para un ledger solo porque escala
La escalabilidad no lo es todo. Para sistemas financieros, la consistencia es innegociable. PostgreSQL con particionamiento maneja millones de transacciones diarias con ACID completo. CockroachDB ofrece escalabilidad horizontal con SQL y consistencia serializable — ideal para fintechs que crecen rápido.
La regla práctica: si tus datos tienen relaciones, requieren auditoría, o implican dinero, empieza con SQL. Migra a NoSQL solo si tienes un cuello de botella específico y demostrable que SQL no puede resolver.
4. Asigna un «dueño del costo» en tu equipo técnico
El error de Uber no fue solo técnico — fue organizativo. Nadie tenía la responsabilidad explícita de monitorear y optimizar los costos de infraestructura. En startups pequeñas, este rol suele caer en el CTO o en el ingeniero senior más senior. Pero debe ser explícito.
- Configura alertas de presupuesto en tu proveedor cloud (AWS Budgets, GCP Budget Alerts).
- Revisa el desglose de costos mensualmente, no cuando llegue la factura sorpresa.
- Usa herramientas como Infracost, OpenCost o CloudZero para vincular el costo a decisiones de arquitectura concretas.
El contexto más amplio: ¿cuánto gastan las fintechs en infraestructura de datos?
El caso de Uber no es una anomalía. Los costos de base de datos representan típicamente entre el 20% y el 50% del presupuesto total de infraestructura en compañías fintech a escala. La presión por velocity y la normalización de usar servicios gestionados cloud han llevado a muchos equipos a acumular deuda técnica económica sin saberlo.
En el ecosistema hispanohablante, donde el capital es más escaso que en Silicon Valley, estos errores son más costosos proporcionalmente. Una startup fintech en México o España que gasta $40,000 mensuales en AWS cuando podría gastar $12,000 está quemando runway que podría ser la diferencia entre una ronda y el cierre.
La pregunta que todo founder debería hacerse no es «¿funciona esto?» sino «¿cuánto nos costará esto cuando tengamos 10x los usuarios actuales?».
Conclusión
Uber gastó aproximadamente $8 millones por elegir la tecnología correcta para el problema equivocado. La lección no es que DynamoDB sea mala — es que toda decisión de arquitectura tiene un costo económico que debe evaluarse junto al técnico.
La buena noticia: construir bien desde el inicio es más barato que migrar billones de registros después. Y a diferencia de Uber, la mayoría de las startups no pueden darse el lujo de aprender esta lección a $8 millones.
La mala noticia: los incentivos que llevaron a este error siguen intactos en la mayoría de los equipos. Nadie es despedido por elegir lo «obvious choice». Pero tu runway sí se acorta.
Fuentes
- https://news.alvaroduran.com/p/nobody-got-fired-for-ubers-8-million (fuente original)
- https://www.uber.com/us/en/blog/migrating-from-dynamodb-to-ledgerstore/ (Uber Engineering Blog)
- https://www.infoq.com/news/2024/05/uber-dynamodb-ledgerstore/ (InfoQ)
- https://www.devnotesdaily.com/p/uber-migrates-1-trillion-records-save-6-million-annually (DevNotes Daily)
- https://newsletter.systemdesign.one/p/payment-system-design (System Design Newsletter)
- https://blog.pragmaticengineer.com/distributed-architecture-concepts-i-have-learned-while-building-payments-systems/ (The Pragmatic Engineer)
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
