Real World Microservices gRPC vs Event Sourcing

Question

I am trying to learn about microservices, and am confused about which approach is better between service orchestration and event sourcing ( service choreography) . There seems to be very few frameworks available which allow you to just build your application using Event Sourcing. Rather, it seems you have to build the whole framework yourself, which is very difficult.

Also, most of the talks on the web of companies actually doing microservices seem as if they are using gRPC( or some other rpc) and orchestration with direct calls between the services, as opposed to event sourcing with sagas/events.

What is the best way to go about implementing microservices ? Using gRPC with service orchestration, or actually trying to implement an event sourced system with service choreography and asynchronous events ?

Nautch

They are orthogonal. You can do both at the same time. – Afternoon

Not sure why you would do both ? If you are going to use rpc and create service dependencies, then why introduce the complexities of event sourcing, apart from contrived examples like sending an email ? On the other hand if you are using ES then why sprinkle in rpc ? It seems like they are mutually exclusive, and the preferred route is ES but due to its complexity most people are using RPC and not the over complicated ES. – Nautch

you are mixing concepts. Event sourcing is just a different persistent type. You can use domain events and not having Event sourcing, i.e. CQRS. So, you are mixing the communication style between microservices with internal microservice persistence. Also, in a system architecture, one could mix how each microservice is implemented: one microservice could be event-sourced and others not, or any other combination. – Afternoon

This may help: https://mcmap.net/q/805230/-microservice-architecture-carry-message-through-services-when-order-doesn-39-t-matter – Afternoon

I totally get that, it just seems that using rpc totally goes against the tenets of EDA, in that all communication is happening directly between the services rather than indirectly via some messaging layer. Furthermore, it seems as if there is a trend towards rpc and this direct mode of communication via rpc as opposed to ES. I just dont see that many companies are using ES and CQRS in its true form, as opposed to rpc. Maybe its because it is much more complex, and seems to require some amount of framework development, as not too many tooling options are available. – Nautch

It may be that they would need senior engineers for that and seniors are hard(er) to find. Or they don't want to pay a senior and choose juniors. The special thing with CQRS/ES is that frameworks are too few, just like you said and juniors love to use a framework. – Afternoon

ES/CQRS is maybe overkill for the application you're building? It makes alot of sense to use these 2 in a very small problem set, most likely one that you're not working in (financial/trading applications, maybe something extremely audited like a power plant or medical device?). The promises for cqrs/es are awesome but just not often requirements. I've found rpc to be a good fit for almost everything. The #1 advantage being that it's simple. Debugging a failed call is like reading the stack trace of every previous call to get there.. – Incitement

Mostly orthogonal concerns but you may want to consider the semantics of domain events and commands in the context of GRPC (bidi-)streaming. – Halter

Answer 1

RPC for retrieving data and messaging to express intentions (commands) and provide integrations/side effects (events).

There are two ways to decompose and integrate distributed systems. One is easy, and the other one is better. The easy way to do things is orchestrated or declarative. The basic idea of an orchestrated system is that one entity tells another entity what to do. The other way to organize your services is through choreography and/or reactivity. Choreography solves the problems we face in declarative systems, like high coupling and low cohesion.

Changes in downstream services may not disrupt upstream services.

Messaging De-duplicator and Re-sequencer, and Distributed Transactions are some heritages from declarative systems and/or from Business Capability Decomposition. In this case, each Entity is represented by only one model for all services, which requires Distributed Transactions and blocking requests to deal with "transactional information between bounded contexts";

On the other hand, one of the main characteristics of subdomain decomposition (DDD) is autonomy, where each Aggregate detains all entities it needs to respond in isolation for each side-effect (business facts/domain events);

Reactive DDD (Domain-Driven Design) is an approach to software development that combines principles from Domain-Driven Design and Reactive Programming to build highly extensible, scalable, and resilient systems. Reactive DDD focuses on modeling the domain's behavior in distributed, event-driven, inherently reactive systems.

Subdomain decomposition is an essential part of DDD, and in Reactive DDD, the subdomains are decomposed to support Choreographed event-driven architectures. Each subdomain is responsible for managing its own state, and changes to that state are communicated through events.

Event-Sourcing is the most efficient/appropriate persistence strategy here, given the eventual nature of the design.

In an eventual and unpredictable environment about when an event occurs, how often the broker will deliver it, and in what order the subscriber will process it, Reactive DDD can help ensure that the system remains responsive and resilient by modeling such "uncertainties."

By modeling the domain as a set of reactive components that communicate through events, the system can be designed to handle large volumes of requests, maintain consistency and reliability, and gracefully recover from failures.

Reactive DDD is a modern and trendy approach becoming increasingly popular for building complex distributed systems. It provides a way to decompose a domain into smaller, more manageable pieces and design them to support a reactive architecture. This can lead to more responsive, scalable, and resilient systems and can better handle the demands of an eventual environment.

If you're interested in modeling uncertainty with Reactive Domain-Driven Design (DDD), here are a few resources that might be helpful:

• Modeling Uncertainty with Reactive DDD (article) by InfoQ
• Reactive DDD—When Concurrent Waxes Fluent (presentation) by InfoQ
• Vaughn Vernon Uses Reactive DDD to Model Uncertainty in Microservices (news article) by InfoQ
• Vaughn Vernon: Reactive Domain-Driven Design (news article) by InfoQ
• Reactive DDD: Modeling Uncertainty - Vaughn Vernon

Trainband