Event-Driven Micro Services Architecture (In a Nutshell).

This is a long story short description of the different aspects of Event driven micro services architecture.

What is a monolith?

It contains Routing | Middle wares | Business Logic | Database access to implement ALL FEATURES of an app.

What is a micro service?

It contains Routing | Middle wares | Business Logic | Database access

to implement ONE FEATURE of an app.

Data in Micro service:

Most challenging aspect in MSA is Data management between services.

- Each service gets its own db if it needs one.

- A service will never reach into another service db.

Why?

- Every service should run independently of other service(s).

- db schema/structure might change unexpectedly.

- Some services might function more efficiently using different types of db's.

A Database-Per-Service approach is adopted with MSA

Communication Strategies Between Services:

- Synchronous: Services communicate with each other using direct requests.

• pros:

1. Easy to understand as a concept.
2. One or many services wont need their proper db to make requests, they depend on other services db's.

• cons:

1. It will create a dependency between services, meaning if service A depends on service B with a db, if service B crashes, service A will also crash.
2. If an inter-service request fails, the overall request fails.
3. The entire request is fast as the lowest request.
4. It introduces a web of requests, meaning lot of requests consumption and risk of bottlenecks.

- Asynchronous (Event driven): Services communicate with each other using events using an Event Bus & persist events in relevant services db's.

• pros:

1. Zero direct dependencies between services.
2. Reduces possible failures into single a point (Event Bus).
3. Events are persisted with proper collection segregation. 
4. Services will become extremely fast, hence low latency.

• cons:

1. Data duplication, as events emitted are persisted in almost every service db. (However data storage cost is minimal on cloud)
2. Could reach a high level of complexity.

TIP: Mitigate architecture risks by considering necessary service storage over risks of potential multi points of failure in services architecture. 

References: @StephenGrider

Cheerz,