apidays LIVE Jakarta 2021 - Accelerating Digitisation
February 24, 2021
Building an Event-Driven Architecture
Harin Honestyandi Parandika, Microservice and Middleware Designer at XL Axiata
3. Understand what is EDA
Event Driven Architecture
01
Benefit of EDA
Why Event Driven Architecture
02
What solace role and how it can help EDA
Solace Introduction
03
Summary of the discussion
Summary
04
Agenda
Style
4. Requirement
• Connected Things
• Faster B2B Integration
• Real Time
• Multiple IT System
Integration
• Faster Delivery to avoid
Missing Opportunity
Digital Economy
Challenges
• Multiple Technology
• Multiple Protocol
• Multiple Deployment
Infrastructure
• Integration Complexity
• Development Time
5.
6. “All of the things that
happen within and to
your life are
“events” ”
7. Notifications of change of state
• Events represent the change of
state of something of interest to
Business
• Record of something that has
happened.
• Events can not be changed.
Event Characteristic
Order Created
Payment
Send Notification
10. Monolith to Microservice
10
Legacy
Create an order
Create an order
Create a Payment
Send a SMS notification
Order Service
Create an Order
Create an order
Payment Service
Create a payment
Notification
Service
Send SMS
Notification
Microservices
Monolith
• Scaling is Hard
• No Automation
• Lack of Agility
• Auto Scale
• Auto Heal
• CICD
How The
Integration
Happen?
11. Microservice – API Driven Architecture
11
Order Service
Create an order
Payment Service
Notification
Service
Create a Payment Send a SMS notification
API-Driven Architecture
Order Service
Create an order
Payment Service
Notification
Service
Create a Payment Send a SMS notification
Orchestration Pattern
Stock Service
Calculate Stock
Use
• Everything will be based on API
• Use Standard HTTP Protocol
• Synchronous Interaction
• Strong Coupled
• At least 1 orchestrator Service
• New Requirement, 2 Developments
• Hard to maintain SLA, overcapacity
Request will be dropped
• Point to Point Communication can grow
complex
12. Microservice – Event Driven Architecture
12
• Event Streaming using Event Broker
• Messaging Protocol
• Loosely Coupled
• Asynchronous Interaction
• 1 Event Trigger/Producer
• Multiple Consumer
• New Requirement, Only Develop the
new service
• Overload Request can be stored
Temporary inside Event Broker
Order Service
Create an order
Payment Service
Notification
Service
Create a Payment Send a SMS notification
Event-Driven Architecture Choreography Pattern
Event Broker
Order Service
Create an order
Payment Service
Notification
Service
Create a Payment Send a SMS notification
Event Broker
Stock Service
Use
Calculate Stock
14. Event Broker
According to Gartner, event brokers
“are middleware products that are
used to facilitate, mediate and enrich
the interactions of sources and
handlers in event-driven computing.”
15. Event Broker Type
According to Gartner, There are 3 Type of Event Brokers
1. Queue-Oriented : Pubsub Mechanism -> typically based on creating queues for each consumer (or shared
consumer group) and a routing mechanism to deliver published message to the appropriate queues. Sample :
Solace PubSub+, RabbitMQ, Azure Service Bus, etc.
2. Log-Oriented : based on the concept of an append-only logs of messages. Neither consumers nor the broker will
remove messages when processed. Instead the log is retained and messages are purged as they age or as the
log reaches a pre-determined size limit. This allows for what is called “message replay”. Sample : Apache
Kafka, Amazon Kinesis, etc.
3. Subscription-Oriented : born out of the need to support cloud-native function platform as a service and
serverless architectures. Sample : Amazon EventBridge, Azure Eventgrid, etc.
17. Solace Pubsub+
“A complete event streaming and
management platform for the real-time
enterprise.”
Three Deployment Options
1. Event Broker: Cloud is a managed service. Spin up event broker
services in minutes, scale to any level, and leave the operation of
your messaging infrastructure to us. Free service available.
2. Event Broker: Software is easy to deploy in your favorite clouds,
containers, and iPaaS/PaaS environments. And there’s a free
production-ready edition.
3. Event Broker: Hardware gives you extreme performance and
capacity in a compact form factor with the operations and low TCO
of a turnkey appliance.
18. Key Features
Topic Hierarchy
Hierarchy Sample :
{Domain}/{Type}/{Brand}/{Activity}
Sample Use Case Commerce :
Publish :
product/laptop/hp/purchase
product/laptop/dell/purchase
Topic Wildcard
Topic Wildcard :
* : for 1 level
> : for multiple level until the end
Sample Use Case Commerce :
Subscribe for all laptop Purchase Event :
product/laptop/*/purchase
Subscribe for all Product Event :
product/>
19. Key Features
Event Mesh
“an architecture layer that allows
events from one application to be
dynamically routed and received
by any other application no matter
where these applications are
deployed (no cloud, private cloud,
public cloud). ”
PaaS
Event Broker Event Broker Event Broker
Event Broker
20. Event Mesh
with Solace
PubSub+
Platform
Dynamic : self-routing, self-learning and self-
healing for automated and efficient event
streaming between event producing and
consuming applications wherever they run.
Open: natively supports multiple open protocols
and APIs, for an open ecosystem.
Simple: provides a single management console
for event mesh creation and management.
Everywhere: can be deployed on premises, in
private clouds, in public clouds (AWS, Azure,
GCP), in containers, appliance, etc.
21. Sample Use Case
Backend
Microservice
LOG
Data Warehouse
... Mobile Apps ... ...
Front-End Micro-Services
Payment
Distribution
Cache
batch polling
~24hrs
interval
Public Cloud
On Premise
Partner/Internal
Application
Give Promo per Trx
Batch/Not
Real Time
Direct
Call API
• Very Poor Customer
Experience
• More Development
Time
• High Complexity
• Missing Opportunity
22. New Event Driven Microservices Architecture
Middleware
Data Warehouse
Payment
Distribution
REST
POST
Pub/Sub + Queueing + Request/Reply + Streaming
... Mobile Apps ... ...
Front End Microservices
REST, MQTT
DMR
Transaction Events
topic
publish
topic
subscription
Partner
Internal App
topic
publish
REST, MQTT
Public Cloud
On Premise
• Faster Delivery
Time
• Low Complexity
• Real Time
• Getting the
Opportunity
• Great Customer
Experience
24. Why Use
Event-Driven
Architecture
• Asynchronous — allows resources to move freely to the next
task once their unit of work is complete, without worrying about
what happened before or will happen next and avoid blocking.
• Loose Coupling — Services don’t need (and shouldn’t have)
knowledge of, or dependencies on other services.
• Easy Scaling — Since the services are decoupled under an
event-driven architecture, and as services typically perform only
one task, tracking down bottlenecks to a specific service, and
scaling that service (and only that service) becomes easy.
• Recovery Support — An event-driven architecture with a
queue can recover lost work by “replaying” events from the
past. This can be valuable to prevent data loss when a
consumer needs to recover
An event-driven architecture offers several advantages over REST, which
include
25. When to Use
API-Driven Architecture
• You need a time-bound request/reply interface
• Convenient support for transactions
• Your API is available to the public
• Your project is small (REST is much simpler to
set up and deploy)
Event-Driven Architecture
• Multiple subsystems must process the same
events.
• Real-time processing with minimum time
lag.
• Complex event processing, such as pattern
matching or aggregation over time
windows.
• High volume and high velocity of data.
26. 1
1 Require a Queue-Oriented Event Broker
3 The luxury of Built-in Multi Protocol
2 Flexibility on Topic Hierarchy
4
Build a Dynamic Event Mesh with
Multi Cloud, On Premise and Hybrid
Deployment
Use Solace Pubsub+ when