Choosing the best backend comms pattern - EDA

We chose the Event-Driven communication pattern (which is inherently async), as this is best for microservices

There’s essentially two choices when it comes to the system’s communication pattern: 

• Event-Driven Architecture (EDA) (ie info/events are pushed as they happen) is a software design pattern that allows decoupled applications to asynchronously publish and subscribe to events (ie significant occurrences or state changes) through an event broker (modern messaging-oriented middleware). where each service produces, detects, consumes, & reacts (aka publish & subscribe) to events within the system. Systems following this architecture usually have asynchronous communication/messaging.

• Request-Driven Architecture (ie services continuously poll/pull for updates) which uses a request and response model. This is how most APIs and systems worked traditionally. Systems following this architecture usually have synchronous communication/messaging.

We chose event-driven architecture as it’s ideal for microservices-based systems. Each microservice can publish events to a message broker and interested microservices can subscribe to those events. More specifically it:

• No waiting & it’s push rather than pull: Everything happens as soon as possible, and nothing is waiting on anything else.

• Scalable: You don’t have to consider what’s happening downstream, so you can add service instances to scale.

• Performant: Topic routing and filtering can divide up services quickly and easily, as in command query responsibility segregation.

• Flexible: To add another service, you can just have it subscribe to an event and have it generate new events of its own; there’s no impact on existing services.

• Reliable: When an error occurs it will be wrapped up in a single service, and it won't cascade to other parts of the system.

To achieve the EDA communication pattern, we chose Kafka as the event broker and chose GraphQL as the comms protocol

When looking to implement EDA, there’s a few critical architectural pieces to implement (Event broker, Event portal, Topics, Event mesh, Deferred execution, Eventual consistency, Choreography, Command Query: Responsibility Segregation / CQRS).

We chose Kafka as our event broker. 

For the communication protocol, we had a few choices:

• REST - This was created to guide how services on the internet / world wide web would talk to each other. It focuses on calling a specific service, choosing from a number of potential endpoints, and awaiting a response.

• GraphQL (by Meta) - is more flexible in that a service can just state what data it needs (ie subscribe) and wait for other entities which it doesn’t know explicitly about to publish. Each service just has one endpoint. A Crash Course In GraphQL

• gRPC (by Google) - Usually used for server-to-server communication

We chose GraphQL as it has greater performance and flexibility than REST and greater popularity/familiarity than gRPC. More than just flexibility, it aligns with our EDA microservice approach. If we did something like REST, each service would have to know about each other and negate the benefits of this approach.