SQS, SNS, EventBridge o Kinesis: ¿cuál usás?

Los cuatro mueven mensajes. Los cuatro son serverless. Los cuatro aparecen en casi todos los diagramas de arquitectura que vas a ver de AWS. Y la pregunta que más me hacen es siempre la misma: ¿cuál elijo para mi proyecto? La respuesta corta es “depende”. La respuesta larga es este post — con un árbol de decisión al final que resuelve la duda en menos de 30 segundos. 💡 No compiten entre sí, resuelven problemas distintos Antes de entrar en cada uno, sacate una idea de la cabeza: SNS no es la versión vieja de EventBridge, y Kinesis no es “SQS pero más caro”. Cada uno existe para un problema diferente. Cuatro analogías simples y te queda clarísimo: * SQS es una fila del banco — dejás un mensaje y el cajero (un solo consumidor) lo atiende cuando puede. * SNS es un grupo de WhatsApp — mandás un mensaje y todos los que están en el grupo lo reciben al mismo tiempo. Si alguien no está mirando el teléfono, se lo pierde. * EventBridge es un operador telefónico inteligente — recibe la llamada y la conecta con el departamento correcto según lo que decís, no solo según a quién iba dirigida. * Kinesis es una cinta transportadora — los datos fluyen sin parar, en orden, y varias estaciones de trabajo pueden leer de la misma cinta al mismo tiempo, incluso volver atrás si hace falta. Con eso en la cabeza, vamos servicio por servicio: SQS Tu opción cuando necesitás desacoplar dos servicios y absorber picos de tráfico sin perder nada: los mensajes quedan guardados hasta 14 días. Tiene dos sabores: Standard (rapidísimo, orden no garantizado) y FIFO (orden sagrado, con límite de velocidad). No lo uses si el mismo mensaje tiene que llegar a varios consumidores a la vez. SNS El rey del fan-out: publicás una vez y disparás varias acciones en simultáneo (un email, una alerta, un log). El dato que a casi todos les agarra de sorpresa: SNS no tiene memoria. Si el suscriptor no está disponible en ese momento, el mensaje se pierde. Por eso el combo más clásico en arquitecturas serverless es SNS + SQS : fan-out inmediato con la resiliencia de la cola detrás. EventBridge Como SNS pero con cerebro: puede leer el contenido del evento y rutearlo con reglas (”si el pedido es de más de $500, mandalo a auditoría”). Es también el que trae conectores nativos para Stripe, Shopify, Auth0 y otros SaaS, si estás arrancando una arquitectura event-driven desde cero, probablemente sea tu punto de partida. Kinesis Honestamente, la mayoría de los proyectos no lo necesitan. Es para flujo masivo y continuo de datos: logs de miles de servidores, clicks de millones de usuarios, sensores IoT. La diferencia clave con SQS es que los datos no desaparecen al leerlos, podés hacer replay si algo sale mal. Si estás dudando si lo necesitás, probablemente todavía no. 🧭 El árbol de decisión de 30 segundos ¿Necesitás que varios servicios reciban el mismo evento? * Sin lógica de ruteo → SNS * Con lógica de ruteo según el contenido → EventBridge ¿Necesitás absorber picos y que el consumidor procese a su ritmo? → SQS ¿Tenés un flujo continuo y masivo de datos que necesitás poder re-leer? → Kinesis ¿Tu caso es simple y no necesitás nada sofisticado? → Empezá con SNS + SQS y evolucioná si hace falta. No hay un servicio “mejor”. Hay uno mejor para tu caso y la complejidad que no necesitás hoy es complejidad que vas a tener que mantener mañana. 🚀 ¿Y cómo se orquestan estos servicios en un flujo real? Estos cuatro suelen aparecer combinados dentro de un proceso más grande, coordinados por Step Functions . Tengo un mini-curso gratuito donde construimos esa orquestación paso a paso — el mismo patrón que uso para automatizar procesos completos sin escribir la lógica de negocio en el código. 🎯 ACCEDER AL MINI-CURSO GRATUITO 💬 Tu turno ¿Cuál de estos cuatro usás más seguido, y cuál te genera más dudas todavía? Contame en los comentarios 👇 This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit desplegando.substack.com