Event-Driven Microservices

The Event-Driven model heavily relies on the QUALITY of events.

Good quality events are:

• explicitly defined via contracts
• have comments
• support evolution with backward and forward compatibility
• support code generation
• breaking changes are well thought

Good events are implemented using the right tools:

• use Avro/Thrift/Protobuf formats and never use JSON!
• use the right event broker (such as Pulsar)

Good events are designed to:

• contain all the info needed by consumers
• use separate streams for each event type
• use the right data types for their fields (don’t use string for numbers, use enums, etc.)
• don’t use type field and fields based on it
• be as small as possible
• consider requirements from consumers
• not just signals - they contain all info needed by consumers

These topics are disclosed in the Chapter 3 of the book we are currently studying:

Our company’s books club has selected a book about Microservices. It is “Building Event-Driven Microservices: Leveraging Organizational Data at Scale” by Adam Bellemare

Chapter 1 contains intro info:

Types of architectures and differences between them:

1. Traditional monolith-style architectures
2. Service-oriented architectures (SOAs)
3. Event-driven microservice (EDM) architectures

Levels of Communication Structures and related Conway’s Law:

• business
• implementation
• data

Problems with traditional architectures (monolith & SOA) when you need to:

• add new business requirement
• grows the team and separate it into two teams

And how these problems are avoided when you use EDM architecture