SAA-C03
Deep Dive
El desacoplamiento es clave para arquitecturas resilientes. SQS añade buffers entre componentes, SNS distribuye mensajes a múltiples suscriptores, y EventBridge conecta servicios con eventos. El examen presenta escenarios donde debes elegir el servicio correcto.
Contenido
SQS es un servicio de colas de mensajes completamente gestionado. Los producers envían mensajes a la cola y los consumers los consumen a su propio ritmo. Desacopla completamente producer de consumer.
Parámetros clave SQS
Visibility Timeout
Tiempo que un mensaje es invisible después de ser leído. Default: 30s. Si consumer no lo deletes, vuelve a la cola.
Message Retention
Cuánto tiempo vive el mensaje. Default: 4 días. Max: 14 días.
Long Polling
WaitTimeSeconds=1-20. Reduce llamadas vacías. Más eficiente que short polling.
Delay Queue
DelaySeconds=0-900. Retrasa entrega de nuevos mensajes.
SQS Standard vs FIFO
Standard Queue
•Throughput ilimitado
•Al menos una entrega (puede duplicar)
•Orden best-effort (no garantizado)
•Para mayoría de casos
FIFO Queue
•Hasta 3.000 msg/s con batching
•Exactamente una vez (no duplicados)
•Orden estricto (First-In-First-Out)
•Para pagos, inventario, auditoría
DLQ (Dead Letter Queue)
Mensajes que fallan N veces (maxReceiveCount) se mueven a DLQ para análisis. Configura alarmas en DLQ para detectar problemas.
SNS es un servicio de notificaciones pub/sub. Un producer publica en un topic y todos los suscriptores reciben el mensaje simultáneamente. Push-based: SNS envía a los suscriptores (no los suscriptores consultan).
SQS Queue
Lambda
Email / Email-JSON
HTTP/S endpoints
SMS / Mobile Push
Kinesis Data Firehose
Tipos de suscriptores que soporta un SNS Topic
Diferencia clave SNS vs SQS
SNS = Push — SNS envía el mensaje a todos los suscriptores inmediatamente. No hay persistencia en SNS.
SQS = Pull — El consumer consulta la cola para obtener mensajes. Los mensajes persisten hasta 14 días.
EventBridge es un event bus serverless. Conecta aplicaciones usando eventos de servicios AWS, SaaS de terceros (Zendesk, Shopify) o aplicaciones propias. Más potente que SNS para event-driven architectures.
Event Rules
Filtra eventos por patrón (ej: "solo eventos EC2 instance-state-change en running") y enruta a targets. Múltiples targets por regla.
EC2 termina → EventBridge → Lambda + SNS + SQS simultáneamente
Scheduled Events (Cron)
Ejecuta reglas en un horario definido. Reemplaza a CloudWatch Events para scheduling.
"Ejecutar Lambda todos los lunes a las 8am UTC"
El patrón Fan-out combina SNS + SQS: un producer publica en SNS, que distribuye el mensaje a múltiples colas SQS. Cada servicio consumer tiene su propia cola y procesa a su ritmo.
Por qué Fan-out en lugar de múltiples colas directas
Producer simple
El producer publica a un solo topic SNS. No necesita saber cuántos consumidores hay.
Buffer por servicio
Cada servicio tiene su cola SQS independiente. Si uno falla, los otros siguen funcionando.
Escalabilidad
Añadir un nuevo consumer = añadir una suscripción SNS. Sin modificar el producer.
| Servicio | Modelo | Persistencia | Cuándo usar |
|---|---|---|---|
| SQS | Pull (consumer consulta) | Hasta 14 días | Buffer, desacoplar, procesamiento a ritmo propio, retry automático |
| SNS | Push (SNS notifica) | No persiste | Fan-out, alertas, notificaciones a múltiples suscriptores |
| EventBridge | Event bus | No persiste (archive opcional) | Event-driven, integración SaaS, scheduled tasks, routing complejo |
Trampa de examen
Si el escenario menciona "mensajes no se pierdan si el servicio cae" — necesitas SQS (persiste). Si menciona "múltiples servicios deben recibir el mismo mensaje" — SNS fan-out o EventBridge. Cada servicio tiene su propio ritmo de procesamiento.
Un mensaje SNS distribuido a múltiples colas SQS independientes.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una aplicación de e-commerce necesita procesar órdenes de compra de forma que: (1) el servicio de inventario, facturación y notificaciones procesen cada orden de forma independiente, (2) si un servicio falla, los mensajes no se pierdan, (3) cada servicio procese a su propio ritmo. ¿Cuál es el mejor diseño?