| Aspecto | A: síncrona | B: SQS FIFO (LocalStack) | B: outbox (Postgres) |
|---|---|---|---|
| Respuesta al estudiante | Resultado final en el request (201 / 409) | 202 aceptado; resultado después | 202 aceptado; resultado después |
| Aceptación bajo estampida | ~50%, luego agota el pool | Pendiente de medir en AWS real | ~75% |
| Overselling | 0 | 0 en pruebas locales | 0 (12,000 = 400 × 30) |
| Tiempo de drenado | No aplica | 371 s en la 1.ª corrida, antes de paralelizar el worker | ~17 s |
| Mensajes fallidos (DLQ) | No aplica | Sin medición final | 0 |
| El encolado toca la BD | Sí, todo ocurre en la BD | No, va a AWS | Sí, compite con el worker |
| Despliegue objetivo | Cualquiera | Instituciones en la nube | Instituciones on-premise |
← Volver a productos
Prototipo validado bajo carga
Matrícula sin caídas: la estampida, absorbida.
Una capa de control de concurrencia que se coloca delante del sistema existente de la institución, no un reemplazo. Comparé una arquitectura síncrona contra una con cola sobre el mismo backend: la cola acepta más solicitudes bajo estampida y ninguna de las dos vende cupos de más.
~75%de solicitudes aceptadas con cola, frente a ~50% síncrona
0sobreventas en todas las variantes y pruebas
12,000matrículas exactas: 400 secciones × 30 cupos
~17 spara drenar la cola (backend outbox)
01 · El problema
Miles de estudiantes, los mismos segundos, los mismos cupos.
Lo que pasa hoy
Cuando se abre la matrícula, los sistemas síncronos colapsan en el pico.
- Lentitud y timeouts en el peor momento.
- Cursos bloqueados aunque tengan vacantes.
- Riesgo de confirmar más matrículas que cupos.
Tres garantías
- Sin overselling: nunca se confirman más matrículas que cupos.
- Orden por sección: quien pidió primero obtiene el último cupo (FIFO como regla de negocio).
- Sin agotar la base de datos: el pico se absorbe sin saturar el pool de conexiones.
02 · Arquitecturas evaluadas
A procesa dentro del request. B encola y procesa después, a su ritmo.
Ambos backends de cola de la Variante B están detrás de la misma interfaz (IEnrollmentQueue): un solo código sirve a instituciones en la nube y on-premise.
03 · Resultados
Bajo estampida, la cola acepta 25 puntos más sin vender de más.
Rampa de hasta 20,000 req/s con k6. El costo de la cola es que el resultado final llega diferido.
Aceptación bajo estampida
Prueba base de la Variante A: 2,000 usuarios virtuales sobre 40 secciones de 30 cupos dieron exactamente 1,200 matrículas y 800 rechazos, con p95 de 745 ms por request.
Cómo leer los números
- Lo comparable entre variantes es la tasa de aceptación y la corrección. La latencia de k6 no: en A mide la matrícula completa y en B solo el encolado.
- Ambas arquitecturas dependen del pool de conexiones de Postgres. Escalar el procesamiento requiere más capacidad de base de datos, no solo la cola.
- Los 371 s de SQS no son representativos: el worker procesaba en serie sobre LocalStack en una laptop. Ya procesa lotes de 10 en paralelo.
- Todas las cifras son locales. Las definitivas saldrán del despliegue en AWS, con app, base de datos, cola y k6 en la misma región.
04 · Historial de avance
De definir el stack a dos variantes medidas, en unas dos semanas.
NestJS
TypeScript
Prisma
PostgreSQL
AWS SQS FIFO
ECS Fargate
Terraform
k6
Docker
Fase 1
Diseño pensado para el pico
La arquitectura aísla el punto de mayor presión del sistema: los cupos. El resto de tu plataforma sigue respondiendo con normalidad.
Fase 2
Cero sobreventas, comprobado
2,000 estudiantes compitiendo por 1,200 cupos: se asignaron exactamente 1,200. Ni uno más, ni uno duplicado.
Fase 3
Cola inteligente por sección
Cada solicitud recibe respuesta inmediata y se atiende en orden de llegada. 2,000 solicitudes aceptadas en 4 segundos.
Fase 4
Funciona en la nube o en tus servidores
Dos modalidades con el mismo resultado: 12,000 matrículas procesadas sin errores, con la cola despejada en 17 segundos.
Fase 5
Infraestructura que crece sola
Despliegue automatizado que suma capacidad cuando sube la demanda y la reduce al terminar. Pagas por el pico solo mientras dura.
Hoy
Listo para un piloto
Buscamos una institución para implementarlo en su próxima temporada de matrícula, con acompañamiento directo durante todo el proceso.
Para instituciones educativas
¿Tu institución sufre cada temporada de matrícula?
Busco una institución piloto. Se instala delante de tu sistema actual, sin reemplazarlo. Modelo: implementación más licencia anual por estudiante.