Qué necesita una plataforma para soportar alta volumetría — 2 casos reales

Dos plataformas, dos realidades de volumen completamente distintas. Ninguna de las dos se nombra por su marca comercial — lo que importa acá son los números y las decisiones de arquitectura que exigieron, no de quién son.

Los números primero

Una plataforma de medios de pago: 180,000 comercios en la red, 110,000 activos (~61% de activación). Cada transacción es dinero real — cero tolerancia a pérdida de datos. En un día regular sostiene 15 TPS, ~54,000 transacciones por hora, ~38.9 millones al mes. En el pico —fin de semana largo, feriado, campaña de cashback— sube a 25 TPS, ~90,000 transacciones por hora, ~64.8 millones al mes. Un incremento de +67% en TPS frente a un día regular.

Una plataforma de movilidad, SaaS Taxi: 5,000 conductores y 75,000 pasajeros registrados, 1,200 conductores activos simultáneos en promedio, reportando ubicación cada 3-5 segundos. Eso equivale a ~300 TPS de tracking sostenido, ~1.08 millones de actualizaciones de ubicación por hora, 450,000 viajes al mes. El dato que más sorprende a una audiencia técnica: el tracking de ubicación por sí solo genera un volumen comparable al de plataformas de altísima concurrencia — sostenido durante toda la operación diaria, no como pico puntual.

No toda plataforma de alta volumetría es igual

El primer caso vive de picos: la exigencia es absorber un salto de +67% sin degradar la autorización de una transacción. El segundo vive de una carga continua: la exigencia es sostener ~300 TPS todos los días sin saturar el sistema. Son dos problemas de arquitectura distintos, aunque ambos se llamen "alta volumetría" — diseñar para uno no resuelve el otro.

Planificar: las preguntas antes de escribir código

Antes de diseñar una sola línea de arquitectura, hay que responder: ¿cuál es el volumen actual y cuál el proyectado a 12-24 meses? ¿Cuáles son los picos conocidos (campañas, feriados, eventos) y cuáles los inesperados? ¿Qué parte del negocio no puede fallar nunca, y qué parte puede degradarse controladamente? ¿Qué SLA exige el negocio, no la tecnología?

Un mal alcance no genera solo sobrecostos — genera caídas justo en el momento de mayor exposición comercial. Y la volumetría no es solo un reto de infraestructura: técnica, operación, marketing/growth y negocio necesitan medir con los mismos datos, porque una campaña mal coordinada con el equipo técnico puede multiplicar por 2-3x el TPS esperado sin que nadie lo haya visto venir.

Diseñar y construir: los pilares no negociables

Microservicios desacoplados que escalan de forma independiente. Escalabilidad horizontal como norma, no como excepción. Diseño stateless en los servicios críticos de tráfico — cualquier instancia debe poder atender cualquier solicitud, sin memoria local que la haga irremplazable.

¿La plataforma puede caer? Sí. Ninguna, por bien diseñada que esté, tiene garantía absoluta de cero caídas. La pregunta que de verdad importa es: ¿cómo se recupera?

La madurez de una plataforma no se mide evitando el 100% de los incidentes — se mide en el tiempo de detección, el RTO (tiempo máximo aceptable para volver a operar) y el RPO (dato máximo tolerable de perder). El circuit breaker detecta cuando un componente dependiente está fallando y deja de llamarlo temporalmente, para que su falla no se propague en cascada al resto del sistema — como un fusible que se abre antes de quemar todo el circuito. A eso se suman retries controlados (reintentar con criterio, no a ciegas), bulkhead (aislar recursos por dominio para que la falla de uno no ahogue a los demás) y arquitectura multi-región para los servicios que no pueden depender de una sola zona.

Idempotencia y contenedores efímeros

Dos conceptos sostienen esa recuperación. La idempotencia: ejecutar una operación 2+ veces produce el mismo resultado que ejecutarla una vez — permite reintentar sin miedo a cobros o viajes duplicados. Y los contenedores efímeros: cada unidad de cómputo se reemplaza en segundos, sin intervención humana, en vez de intentar repararla en caliente. Reemplazar, no reparar.

A esto se suma observabilidad end-to-end — trazar cada transacción de punta a punta es la diferencia entre encontrar la causa raíz en minutos o en horas —, seguridad por diseño desde el primer commit, y mensajería asíncrona (colas, backpressure, rate limiting) para absorber picos sin perder datos.

Operar: donde se nota la experiencia real

Las herramientas —Kafka, Kubernetes, Redis, cloud— están al alcance de cualquiera. La diferencia real es haberlas operado bajo presión real, con el negocio de un cliente dependiendo del resultado: saber qué falla primero cuando sube la carga, tener criterio sobre dónde invertir en resiliencia y dónde no, y reaccionar en producción con guardias, runbooks y postmortems — no improvisando.

Un dashboard de negocio y uno técnico deben hablarse entre sí: una caída de conversión puede ser síntoma de un problema técnico que todavía no disparó ninguna alerta de infraestructura.

Cierre

idtt. no vende infraestructura — vende capacidad de operar el negocio sin fricción en el momento de mayor demanda. Diseño para la volumetría proyectada, no solo la actual; equipo con experiencia real operando bajo presión; visión 360 del negocio completo; soporte y observabilidad continua desde el día 1.

¿Conversamos sobre la volumetría de tu plataforma?