Hay un meme que dice 'ningún CTO fue despedido por elegir Kafka'. Es gracioso porque es verdad — pero también es verdad que la mayoría de las empresas que adoptaron Kafka no lo necesitaban. Event-driven architecture (EDA) es una herramienta poderosa para problemas específicos. Aplicada a problemas equivocados, agrega complejidad sin valor.
EDA tiene sentido cuando tenés alguno de estos tres: alto volumen con consumidores múltiples del mismo evento (ej: una orden de compra que dispara stock, facturación, logística, CRM); desacople temporal real (productor y consumidor no comparten ventana de disponibilidad); necesidad de replay (poder reprocesar eventos pasados con lógica nueva). Si tu caso no encaja en ninguno, probablemente no necesites Kafka.
Para la mayoría de las empresas medianas, lo que necesitan no es Kafka — son webhooks robustos. Una arquitectura simple con webhooks bien implementados (firma criptográfica, idempotencia, cola de reintentos con backoff exponencial, dead letter queue) resuelve el 80% de los casos. Tarda 2 semanas implementarlo bien y no requiere infraestructura especial.
Cuando sí es momento de Kafka (o NATS, Redpanda, Pulsar), el costo a considerar no es la licencia o el cloud bill. Es el costo operativo: tu equipo necesita saber cómo monitorear consumer lag, schema evolution, dead letter scenarios. Si no tenés gente con experiencia, vas a pagar el aprendizaje en outages.
Nuestra recomendación: empezá con webhooks. Cuando empieces a tener problemas que los webhooks no resuelven (en general cuando manejás más de 100k eventos/día consistentes), evaluá Kafka. Pero no antes, y nunca por hype. La complejidad agregada se paga en deuda operativa que tu equipo no va a perdonar.