Nota de Arquitectura: Cuándo elegir SQS FIFO sobre una cola de base de datos
Un marco de decisiones que utilizo cuando el equipo opta por una cola respaldada por Postgres por defecto.
Parte de Backend Craft
Los equipos recurren a "solo usa una tabla" en las colas más de lo que deberían. A veces eso es correcto. A menudo es una bomba de tiempo.
Mi árbol de decisiones:
- ¿Se requiere ordenamiento por clave? → SQS FIFO con MessageGroupId. Una cola de base de datos solo lo hace bien si tienes cuidado con
SELECT FOR UPDATE SKIP LOCKED. - ¿El rendimiento va a superar unas pocas centenas por segundo? → SQS. Las colas de base de datos compiten con el resto de tu aplicación por conexiones y bloqueos de filas.
- ¿Se necesita exactamente una vez en el consumidor? → Ninguna de las dos te da eso. Diseña consumidores idempotentes; usa la ventana de deduplicación de SQS FIFO como red de seguridad.
- ¿Está el consumidor fuera del radio de explosión de la base de datos? → SQS. No acoples un trabajador externo a tu Postgres principal.
Una cola de base de datos es correcta cuando el trabajo está intrínsecamente ligado a una transacción — "después de que esta fila se confirme, haz X." SQS es correcto cuando el trabajo es extrínseco.
Relacionado
Sigue leyendo
Nota diaria: Hoy aprendí — etiquetas <mark> de Polly SSML
Las etiquetas <mark> de SSML de Polly emiten eventos de temporización a través del flujo. Son útiles para sincronizar los subtítulos en pantalla con la reproducción de voz.
Construyendo Integraciones de Voz sobre Chatbots Asíncronos
¿Qué se rompe cuando enfrentas un chatbot asíncrono con Amazon Connect + Lex, y cómo mantener la latencia, la interrupción y la transferencia de contexto en un nivel razonable?
Lo que aprendí al diseñar integraciones de backend omnicanal
Esquema de intención compartida, estado de conversación eventualmente consistente y por qué el canal debería ser lo último que tu backend conozca.
Continúa
¿A dónde sigues?
Explora más textos técnicos, revisa los casos de estudio o escríbeme directo.