La noche del jueves 7 de mayo, el servicio de trading de Coinbase estuvo inaccesible durante casi 10 horas, dejando a sus usuarios imposibilitados de comprar, vender, depositar, recibir o retirar fondos. Este fallo masivo coincidió con una caída regional en los servicios de Amazon Web Services (AWS), pero, a diferencia de otras compañías, Coinbase sufrió un apagón global total.
Lo llamativo del caso es que Coinbase, una empresa valorada en alrededor de 40.000 millones de dólares, remitió a sus clientes a monitorear la página de estado de AWS para estar al tanto del restablecimiento del servicio, evidenciando así su dependencia exclusiva de una única zona de disponibilidad (AZ) dentro de la infraestructura de AWS.
Este dato lo confirmó la propia plataforma posteriormente, al detallar en un análisis postmortem del incidente que su motor de coincidencia de órdenes (matching engine) se ejecuta dentro de un clúster replicado basado en Raft en un AWS Placement Group específico, es decir, en un solo edificio o AZ. Según explicaron, esta decisión obedece a la necesidad de minimizar la latencia y optimizar el rendimiento en operaciones de trading que requieren alta velocidad y capacidad de procesamiento en tiempo real.
Para entender mejor la cuestión técnica, conviene distinguir entre zona de disponibilidad y región en AWS. Una zona de disponibilidad agrupa varios centros de datos cercanos, con baja latencia entre ellos, pero sin garantias independientes absolutas de disponibilidad. En cambio, una región abarca al menos tres zonas de disponibilidad separadas físicamente, generalmente a decenas de kilómetros de distancia, lo que reduce significativamente el riesgo de que todas fallen simultáneamente.
En este sentido, Coinbase reconoció que operar su motor desde varias zonas de disponibilidad provocaría demasiada latencia, haciendo inviable su modelo. Sin embargo, su gran error fue no implementar un sistema automatizado de failover, una función que permitiría cambiar rápidamente la operación a otra zona en caso de fallo. Cuando AWS canceló las instancias EC2 en la zona primaria a las 21:29 ET, tres de los cinco nodos críticos del clúster dejaron de funcionar y se perdió el quórum necesario para mantener el servicio.
More Read
Este fallo en la arquitectura obligó a que el equipo de ingenieros de Coinbase tuviera que realizar cambios de emergencia en el código para eliminar la suposición de que todos los nodos del clúster estuvieran operativos y, además, configurar manualmente un nuevo grupo de nodos fuera del grupo afectado. A partir de ahí, recuperaron el servicio en modo cancelación de operaciones, luego en modo subasta, y finalmente, restablecieron el trading completo.
La ausencia de un failover automático resulta sorprendente y poco profesional para una plataforma que procesa aproximadamente 5,2 billones de dólares al año y cuya valoración roza los 40.000 millones. Según cálculos aproximados, solo durante esta interrupción quedaron interrumpidas transacciones por un valor cercano a los 7.000 millones de dólares.
Comparativamente, en 2016, Uber, con una valoración similar y manejando entre 40 y 50 billones de dólares anuales, disponía de centros de datos en la costa este y oeste de Estados Unidos y realizaba simulacros regulares de failover a otro centro o región en caso de desastres. Esto indica que, pese a la mayor escala financiera de Coinbase, su resistencia operativa y preparación ante fallos es notablemente inferior.
More Read
El impacto reputacional también ha sido considerable, pues la confianza en la cultura de ingeniería de Coinbase ha mermado tras este episodio. Resulta irónico que, en paralelo, su CEO Brian Armstrong promocione la incorporación de equipos no técnicos en la implementación de código en producción apoyándose en la inteligencia artificial, cuando los fundamentos técnicos básicos sobre infraestructura crítica siguen sin estar adecuadamente garantizados.
Además, este no es el primer aviso de vulnerabilidad en la empresa. En octubre de 2025, Coinbase sufrió una caída global de trading de tres horas por problemas con DynamoDB en AWS. Tras aquel incidente, declararon que explorarían todas las opciones para mejorar su estrategia de despliegue regional y minimizar el impacto de futuras interrupciones. Sin embargo, esta revisión aparentemente pasó por alto el riesgo que implica depender de una única zona de disponibilidad sin fiabilidad cruzada.
Este episodio pone en evidencia la necesidad imperiosa para plataformas financieras de alta demanda de integrar sistemas resilientes y automatizados que garanticen continuidad operativa, así como de revisar a fondo estrategias que hasta ahora comprometen la disponibilidad y seguridad de los servicios críticos para sus usuarios.
