Introduction to Microservices Patterns

Introduction to
Microservices Patterns

Types of Monolith Applications (1)
A) The Single Process Monolith:
● All code is packaged into a single
deployable process.
● All data are stored in one single DB.

B) The Modular Monolith
● Still single process, one deployable
service.
● The code inside the process is
broken down into modules.

C) The Distributed Monolith
● Has all the drawbacks of both monolith
and distributed systems
● Contains multiple services
● Whole ecosystem should be deployed
together.
● Require changes everywhere in the
services.
● Needs deploy coordination.
● Highly coupled.

Advantages of monoliths:
1. Simpler deployment topology, one
deployable file.
2. ACID power – strongly data
consistency.
3. Simplify code reuse.
4. Simplify architecture.
Disadvantages of monoliths:
1. Difficult to scale.
2. Large scope for developer to
familiarise.
3. Development is slow.
4. Lack of isolation and reliability.
5. Long time to test and deploy.
6. Lack of innovation.
Monolith Applications

What are microservices? (1)
Term: Microservices are small, autonomous,
independently deployable services that function
together to implement a business domain.
Goal: Accelerate software development by enabling
CI / CD and improve scaling issues.
Main characteristics:
- Own their own data.
- Modeled around a business domain
(DDD).

What are microservices? (2)
Microservices Advantages:
1. Highly maintainable and testable.
2. Independently scalable.
3. Independently deployable.
4. Loosely coupled.
5. Being technology agnostic.
6. Faster development.
Microservices Disadvantages:
1. Architecture the entire system is
harder.
2. Introduce complexities of
distributed systems (data
consistency, lack of ACID) .
3. Need of cross-services queries to
retrieve data from multiple services.

Challenge: Microservices and Databases
● Each service should own its own data,
have its own database
● Service’s database should be accessed
only by owner service and not from other
services.
● Avoid shared databases - makes sense
only for static data e.g. postCodes.
● We lose ACID power, as multiple
databases are involved for a business use
case.
● Introduces complexity on data
consistency, as enforces eventually
consistency.

Challenge: Clients access Microservices
We need to figure out how clients will be
able to use these services. Let's have a
look at the some options:
1. Direct Client-to-Microservice
Communication.
2. API Gateway.
3. Backend for frontend (BFF).

Pattern: Direct Client-to-Microservice
Communication
Make requests to each of the microservices
directly.
Benefits:
● Easy to implement
Drawbacks:
● Higher latency leads to poor user
experience.
● Mismatch between the needs of the
client and the MS APIs.
● Difficult to refactor the microservices.

Pattern: API Gateway
Benefits
1. Hides from the clients from how the
application is divided into microservices.
2. Responsible for request routing.
3. Reduces the number of requests / roundtrips.
4. Composition.
5. Requests aggregation.
6. Protocol translation.
Drawbacks
1. Increased complexity – must be developed,
deployed and managed.
2. Availability issues.
3. Another point of failure

Features of API Gateway
1. Handling partial failure using the Circuit breaker pattern
2. Limiting the number of outstanding requests from a client to a service
3. Network timeouts
4. Provide fallbacks

Pattern: Backends for frontends (BFF)
Benefits:
● Leading to high development
velocities – as BFFs are client
specific.
● Client applications are protected
from API changes in downstream
services.
● Dedicated Gateway for each client.
Drawbacks:
● Duplication of code

Challenge: Inter-process communication
one-to-one one-to-many
Synchronous Request / Response -
Asynchronous Asynchronous Request /
Response
One way notification
Publish / Subscribe
Publish / Async responses

RESTful APIs
Benefits:
1. HTTP is simple and familiar.
2. Supports request / response style
communication
Drawbacks:
1. Blocking
2. Coupling
3. Cascading failures / Error Handling
4. Lacks replayability

Asynchronous Messaging
Two types of async messaging:
● Brokerless
● Broker-based (Kafka, RabbitMQ,
AWS kinesis…)
The message represents a change in
state, which is triggered when a user or
service performs an action.

Brokers
● Point to Point (1-to-1): message is sent
from one producer to a consumer via a
queue (e.g. AWS SQS). Can be one or more
consumers, listening on this queue but
only one of them will be get the message.
● Publish/Subscribe (1-to-many): message is
sent from one producer to multiple
consumers/subscribers via a topic (e.g.
Kafka, AWS Kinesis). The subscribers may
or may not acknowledge the published
message

Event-Driven Architecture (EDA) (1)
EDA is an architecture design where a service is executed in response of receiving one
or more events. Messages are triggered when a user or service performs an action and
are emitted via topics / queues.
● Services communicate with events, and with APIs where is required.
● Services can produce and consume events.
● Event logs (messages) are the backbone of the system not the data
● Data is eventually consistent

Benefits of EDA:
● Loose coupling
● Flexibility
● Message buffering
● Resiliency
● Replayability
● Implementation of transactions that
span multiple services and provide
eventual consistency
● Enables an application to maintain
materialized views
Drawbacks of EDA:
● Potential single point of failure
● Learning curve
● Losing events if supports at-most-
once delivery.
● Events ordering
● More difficult to design ecosystem

Here is an example of EDA:
● Sources / producers emit the events
to event broker.
● There is a stream processing - this
is different based on broker, eg
kafka has the kstreams and ksql.
● Consumers are registered to specific
topics / streams and consume
events.
● Can have a external database
where we can archive data,
otherwise we can store them inside
the broker

Challenge: Cross-service queries
We want to get data from service A to
service B:
1. Direct HTTP request from A to B
2. Create new aggregator service
3. Creating replication of the data

Challenge: Distributed transactions (1)
How we keep consistency as we have
multiple DBs?
❖ Monolith: One database – We have
the solution of transaction (ACID)
❖ Microservices: Multiple databases -
Distributed databases
➢ How to maintain a
transaction’s automaticity?
➢ How to manage the
transaction isolation level for
concurrent requests?

Challenge: Distributed transactions (2)
Let's have a look at the some options:
1. 2PC transactions.
2. Sagas.

Challenge: Distributed transactions (3) - 2PC
transactions
Two-phase commit (2PC) protocol:
● Prepare phase (Phase 1)
● Commit phase (Phase 2)
Drawbacks:
● 2PC is not a viable option in modern
applications, because of CAP
theory.
● Does not scale.
● Most NoSQL databases, do not
support 2PC

Challenge: Distributed transactions (3) - Sagas
Sagas are sequence of local transactions. Each local
transaction updates the database and publishes a message.
If a local transaction fails, saga executes a series of
compensating transactions to undo changes.
Benefits:
● Maintain data consistency across multiple
microservices without tight coupling (BASE)
● Perform better compared to 2PC.
● Offer no single point of failure.
● Keep the overall state of the transaction eventually
consistent.
Drawbacks:
● Difficult to implement, when a lot of services.

Challenge: Achieving atomicity publishing
event and update database
A service wants to update the database and publish events. The database update
and event publishing must be atomic to avoid data inconsistencies and bugs.
Possible Solutions:
● Outbox pattern using Polling.
● Outbox pattern and CDC using transaction logs.
● Event sourcing

Pattern 1: Outbox Table and Polling
● Make insert / update of the domain model
to DB on a transaction (atomic).
● Add an insert on a new outbox table as
part of the local transaction.
● Polling the DB for new events and fire
event to message broker and mark them
as published.
Drawbacks:
❖ Polling the database can be expensive –
consume a lot of db resources.
❖ Polling works well at low scale.

Pattern 2: Outbox Table and CDC
● Make insert / update of the domain model to DB
on a transaction (atomic).
● Add an insert on a new outbox table as part of
the local transaction.
● Read from generated a transaction log (CDC, like
Debezium).
Benefits:
❖ No distributed mechanism need.
❖ The service publishes domain events.
Drawbacks:
➢ Might publish a message more than once (at-
least-once).
➢ Some DBs does not support CDC.

Pattern 3: Event Sourcing
● Events are stored in an event store.
● Every state change is captured as an event
and stored in sequence.
● Have one source of truth (event store)
● The event store emits events to all
interested subscribers.
● By subscribing to events, you get an
evolving copy of the object’s state.
● Reliable audit log.

General rules to managing data (1)
● Each service manages its own data / database.
● Embrace eventual consistency where possible.
● When you need strong consistency guarantees, one service may represent the
source of truth for a given entity.
● If you need strong consistency among some services, rethink how we split
services so the entities that should be consistent stay in one service.
● Store only the data that a service needs.

General rules to managing data (2)
● Enforce EDA and event sourcing style. Can be used to construct a materialized
view from events which is suitable for querying.
● Try to eliminate sync communication among inter services communication. Try
to enforce async and emit an event.
● Use HTTP when client triggers API GW / BFF.
● Even if we need data that belongs to other service, avoid to rely on sync
requests (cross-service requests), but start using materialized views (local
tables read-only) using EDA and eventual consistency
● The important rule is to try to avoid have synchronous dependencies between
your services.

References
● Microservice Patterns: With examples in Java by Chris Richardson (https://microservices.io/)
● Monolith To Microservices by Sam Newman (https://samnewman.io/books/monolith-to-microservices/)
● Building Microservices by Sam Newman (https://samnewman.io/books/building_microservices/)
● NET Microservices Architecture for Containerized NET Applications (https://docs.microsoft.com/en-
us/dotnet/architecture/microservices/)
● Designing and Deploying Microservices by NGINX (https://www.nginx.com/resources/library/designing-
deploying-microservices/)
● Designing Distributed Systems by Brendan Burns
● Reliable Microservices Data Exchange With the Outbox Pattern
(https://debezium.io/blog/2019/02/19/reliable-microservices-data-exchange-with-the-outbox-pattern/)
● Distributed transactions management by IBM
(https://developer.ibm.com/depmodels/microservices/articles/use-saga-to-solve-distributed-transaction-
management-problems-in-a-microservices-architecture)
● Managing Data in Microservices (https://www.youtube.com/watch?v=E8-e-3fRHBw)
● Creating event-driven microservices (https://www.youtube.com/watch?v=ksRCq0BJef8)
● Decomposition to MS (https://www.youtube.com/watch?v=64w1zbpHGTg)
● Data consistency into MS (https://www.youtube.com/watch?v=CFdPDfXy6Y0)
● Azure Data considerations for microservices (https://docs.microsoft.com/en-
us/azure/architecture/microservices/design/data-considerations)
● Designing event driven systems by Ben Stopford (https://www.confluent.io/designing-event-driven-systems/)

Contact Info
● Arconsis:
○ Website: https://www.arconsis.com
○ Github: https://github.com/arconsis
● Dimos Botsaris:
○ Website: https://www.eldimious.com/
○ Github: https://github.com/eldimious
○ Email: botsaris.d@gmail.com

Introduction to Microservices Patterns

More Related Content

Similar to Introduction to Microservices Patterns (20)

Recently uploaded (20)

Introduction to Microservices Patterns