Event-driven architecture has become the default answer on a lot of architecture whiteboards. A team draws a box labeled “service,” then another box, then between them — instead of an arrow — someone writes “Kafka.” The room nods. The decision feels modern and forward-looking. The design gets approved. Six months later, that same team is debugging a schema-evolution issue at two in the morning, wondering why an event that was produced cleanly three services ago has arrived malformed at the consumer, and why the dead-letter queue has quietly accumulated forty thousand messages that nobody has triaged. Event-driven architecture is a genuinely powerful pattern. It is not a free one. The question a technology leader should ask is not whether the pattern is good — it is. The question is whether the workload properties justify the operational complexity it imposes on the team that has to keep it alive .…