Diferente Da Arquitetura Orientada A Serviços

Event-driven vs SOA: where most teams get it wrong

I spent years designing systems with SOAP endpoints and WSDL contracts, then watched every team I worked with try to replicate that pattern with Kafka and try harder to call it "modern." The core problem is that people confuse the transport layer with the architectural intent. You can build a terrible event-driven system that behaves identically to a bad SOA system, and you can build a competent one that actually solves problems SOA was struggling with. The fundamental difference sits in how services discover and interact with each other. In SOA, the interaction is request-response by default. Service A calls Service B, waits for a response, and moves on. The coupling is synchronous and explicit. In an event-driven architecture, services publish domain events and other services react to them without knowing who published or who will consume. The coupling shifts from point-to-point to publish-subscribe.

Por que isso é diferente da arquitetura orientada a serviços na prática

Here is where the theory meets the floor. I was debugging a payment processing pipeline at a fintech startup in 2023. The system was marketed as event-driven but was actually just a chain of synchronous HTTP calls with messages queued in Redis as a workaround for timeouts. The team had added Kafka but only used it for logging, not for actual service communication. It took three weeks to untangle because the contract definitions, retry logic, and error handling were scattered across twelve different services, each with its own assumption about what "success" meant. The fix was brutal but straightforward. We stopped treating events as logs and started treating them as the source of truth for state transitions. We defined a strict event schema using Avro with backward compatibility rules, set up dead letter queues on every consumer, and implemented exactly-once semantics at the application layer by tracking event IDs in a deduplication store. This cut our mean time to resolution for payment discrepancies from about four hours down to roughly twenty minutes. One counter-intuitive thing nobody mentions: event-driven architectures often create more operational overhead than SOA, not less. With SOA, you know exactly who is calling whom. With events, a single service can have dozens of downstream consumers that are completely invisible in your service mesh unless you invest in proper event governance and schema registries. I've seen production outages where a schema change in a legacy user service silently broke five downstream aggregators, and none of them had integration tests that covered the new field.

Another thing that trips people up is the assumption that event-driven means eventual consistency is acceptable everywhere. It is not. In our payment pipeline, we had to implement a compensating transaction pattern for failed events, which meant every state transition had to be reversible. This added significant complexity to services that previously only needed to handle success and failure cases. The total development time for the first version of the system increased by about 40 percent compared to what a synchronous SOA version would have required. If you are evaluating whether to move away from SOA, the real question is not whether event-driven is better but whether your domain has the right characteristics. Event-driven shines when you have loose coupling requirements, high read-to-write ratios, or when different parts of your system need to evolve independently. It struggles with complex transactional boundaries, real-time consistency requirements, and teams that are small or lack strong DevOps practices. The practical compromise I end up recommending most of the time is a hybrid approach. Keep the core transactional path synchronous with strong consistency guarantees, and use events only for side effects, notifications, and async integrations. This gives you about 80 percent of the benefit of a fully event-driven system with roughly half the operational complexity. Your services still communicate through well-defined contracts where it matters, and the asynchronous parts get the flexibility they need without infecting the entire system.

There is no free lunch here. The tools matter less than the discipline. A well-governed SOA with good observability and clear contracts will outperform a poorly governed event-driven system every time. The architecture you choose should match the problems you actually have, not the ones you read about in conference talks.