Scribd
Upload
5 views21 pages

S2_Slides

The document discusses event-driven architecture and microservices, highlighting their evolution and characteristics. It explains the communication methods between services, specifically commands and queries, and outlines the challenges associated with them, such as performance, coupling, and scalability. Additionally, it differentiates between complete and pointer events, detailing when to use each type in event handling.

Uploaded by

chandanrkambale
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
5 views21 pages

S2_Slides

The document discusses event-driven architecture and microservices, highlighting their evolution and characteristics. It explains the communication methods between services, specifically commands and queries, and outlines the challenges associated with them, such as performance, coupling, and scalability. Additionally, it differentiates between complete and pointer events, detailing when to use each type in event handling.

Uploaded by

chandanrkambale
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 21

Events

Memi Lavi
www.memilavi.com
Events

• The cornerstone of event driven architecture

• Require a well-defined definition

• Evolved from other architectures


Microservices Architecture

• Based on loosely-coupled services

• Each service in its own process

• Lightweight communication protocols

• Polyglot

• No platform dependency between services

• Replaces two legacy architectures


Monolith
SOA
(Service Oriented Architecture)
Typical Microservices System

Service
Service

Service DB

Service
DB
Microservices Communication

• Perhaps the most important part in

microservices architecture

• Dictates performance, scalability,

implementation and more

• Event Driven Architecture handles

the communication part


Command and Query

• The classic communication between services

• Services either:

• Send command

• Query for data


Command

• Service asks another service to do something

Orders Payment
service service
Process payment

Processing completed
successfully

• There might be a response to the command, usually a success or

failure indicator
Query

• Service asks another service for data

Customers Orders
service service
How many orders for customer X?

17

• There’s always a response to the query, containing the data


Command and Query

• Main characteristics:

Command Query
• Do something • Retrieve data
• Usually synchronous • Almost always synchronous
• Sometimes returns a response • Always returns a response
• Calling service needs to know • Calling service needs to know
who handles the command who handles the query
Problems with Command and Query

• Three major problems with command and query:

Performance

Coupling

Scalability
Performance

• Synchronous = the calling service waits for the command / query to

complete

• Potential for performance hit


Coupling

• The calling service calls a specific service

• If the called service changes – the calling service has to change too

• More work, more maintenance


Scalability

• The calling service calls a single instance of a service


• If this instance is busy – there’s a performance hit
• Adding another instances is possible, but difficult
• Add load balancer, configure probes etc.
Event

• Indicates that something happened in the system

Customers
service
New customer was added

• There’s never a response to the event


Event

• Main characteristics:

Event
• Something happened
• Asynchronous
• Never returns a response
• Calling service has no idea who
handles the event
Contents of Event

• Two types of event data:

Complete Pointer
• Contains all the relevant data • Contains pointer to the complete data of the entity
• Usually entity data • Complete data usually stored in a database
• No additional data is required for • Event handler needs to access the database to
the event processing retrieve complete data
• Example: • Example:
event_type: CustomerCreated event_type: CustomerCreated
customer_id: 17 customer_id: 17
first_name: David
last_name: Jones
join_date: 2022-03-15 Pointer
Flow of Complete Event Handling

Customers
service
New customer was added
Event handler

• Receives event data


• Processes the event
Flow of Pointer Event Handling

Customers
service
New customer was added
Event handler

• Receives event data


• Retrieves complete data from database
• Processes the event

Database
Complete vs Pointer

• When to use which?

Complete Pointer
• The better approach • Use when:
• Makes the event completely • Data is large
autonomous • Need to ensure data is up-to-date
• Can get out of the system • Assuming database is a single-source-of-
boundaries truth

You might also like