Distributed Systems Playground
Una cola de mensajes que puedes romper a propósito. Cambia el número de consumidores, la tasa de fallos y el visibility timeout, y mira qué pasa con cada mensaje.
Simulation ModeCorre completamente en tu navegador. Ninguna petición a AWS: todos los números de esta página los calcula el simulador.
Escenarios
Qué observar: Un mensaje solo sale de la cola cuando el consumer lo borra (DeleteMessage). Recibir no es lo mismo que consumir.
Lista para iniciar.
Leyenda
- Primer intento
- Recibido de nuevo (número = recepciones)
- Poison message
- Copia entregada por duplicado
- Aún en proceso con el receipt handle vencido
Configuración
Registra cada mensaje procesado e ignora los repetidos.
La misma seed siempre produce la misma ejecución.
Métricas del simulador
- Tiempo simulado
- 0,0 s
- Enviados
- 0
- Disponibles
- 0
- En proceso
- 0
- Esperando reintento
- 0
- Completados
- 0
- Intentos
- 0
- Fallos
- 0
- En la DLQ
- 0
- Throughput
- 0,0 msg/s
- Tiempo medio
- 0,0 s
- Efectos duplicados
- 0
- Duplicados ignorados
- 0
Eventos
Todavía no hay eventos.
Estado de cada mensaje
| Mensaje | Estado | Recepciones | Efectos aplicados |
|---|---|---|---|
| M01 | En el producer | 0 | 0 |
| M02 | En el producer | 0 | 0 |
| M03 | En el producer | 0 | 0 |
| M04 | En el producer | 0 | 0 |
| M05 | En el producer | 0 | 0 |
| M06 | En el producer | 0 | 0 |
| M07 | En el producer | 0 | 0 |
| M08 | En el producer | 0 | 0 |
Qué muestra esta simulación
At-least-once
SQS Standard garantiza que cada mensaje se entrega al menos una vez, no exactamente una vez. Los duplicados son raros, pero el consumer tiene que tolerarlos.
Orden no garantizado
En una cola Standard el orden es best-effort. Con varios consumers y reintentos, el orden de finalización se aleja aún más del de envío. Si el orden importa, la opción es una cola FIFO, con otros límites.
Visibility timeout
Recibir oculta el mensaje durante un tiempo. Si el consumer no lo borra en ese intervalo, por fallo, bloqueo o lentitud, vuelve a estar visible y se entrega de nuevo.
Dead-letter queue
Cada recepción suma 1 al receive count. Cuando supera el maxReceiveCount de la redrive policy, SQS mueve el mensaje a la DLQ en lugar de entregarlo otra vez.
Idempotencia
Un consumer idempotente produce el mismo resultado si el mismo mensaje llega dos veces. Aquí registra el id de cada mensaje procesado e ignora las repeticiones.
Concurrencia
Más consumers aumentan el throughput mientras haya mensajes disponibles. También aumentan la contención en recursos compartidos y la probabilidad de procesar duplicados al mismo tiempo.
Simplificaciones deliberadas
- No reproduce la planificación interna de AWS: tiempos, orden y duplicados siguen reglas simples y una seed.
- Cada consumer recibe un mensaje a la vez. La Lambda real recibe lotes de hasta 10.
- Un mensaje va a la DLQ en cuanto reaparece con el límite alcanzado. SQS lo hace en el siguiente intento de recepción.
- Las copias duplicadas no se vuelven a entregar si fallan.
- El visibility timeout es fijo: ningún consumer lo extiende y no hay backoff entre intentos.
AWS Live Mode
Existe una versión real de este experimento: API Gateway, una Lambda que produce mensajes, una cola SQS Standard con DLQ y una Lambda consumer con respuestas parciales de lote. Corre en mi cuenta de AWS, por eso está restringida al área de administración, con límites de mensajes y de ejecuciones por día.
API Gateway (ruta autenticada) → Lambda producer → SendMessageBatchCola SQS Standard → event source mapping → Lambda consumerFallo: el mensaje vuelve con retraso; tras 3 recepciones va a la DLQEstado de cada mensaje en DynamoDB, seguido por polling
Esta página nunca llama a AWS. El modo real requiere iniciar sesión como administrador.