Hi CT,

thanks for the message! So the answer to your question is two fold actually:

First off, one of the main idea behind event-driven systems is that services don't communicate directly with each other but instead there's some form of a message/event broker in between them. The responsibility of the broker is essentially to queue up events for consumers to consume (at their own pace). This decouples the microservices since they are technically unaware of each others existence (even with orchestration the orchestrator does not know which service will pick up the command, it just knows it produces the event to the broker). Some examples of message/event brokers are Apache Kafka, AWS SQS (can be combined with AWS SNS), RabbitMQ, AWS EventBridge etc.

To the second point, regarding the central point of failure, you are indeed right! Even though the microservices are decoupled, and your application in general is more available than synchronous communication (http calls between services for example, reason even-driven has higher availability in general is that 1 service going down doesn't mean the whole system is down, where with synchronous communication this would be the case as the failing request cascades), the message/event broker is a single point of failure. Because of this, it's very important to setup the broker in an highly available mode (for example using replica's spread across different machines and/or datacenters. In AWS multi-AZ setup would be beneficial).

To summarise: the event-broker is indeed a single point of failure and is indeed present in both approaches, however it's sole responsibility is queueing events without any orchestration and/or business logic to it. The different between P2P choreography and orchestration lies in how the consumers and producers behave based on the events (either act on themselves in P2P or respond to commands from a central orchestrator service).

Hope this helps clarifying a bit, if not please feel free to reach out.

With kind regards,

Xavyr