From Monolith to Microservices — Part 2

Heru Hermawan

3 min readJun 8, 2020

This is the second part of article “From Monolith to Microservices”

Design Microservices

Domain-Driven Design

One key principle of domain-driven design is divide and conquer

The bounded context is at the heart of a microservices design

Twelve Factor Applications

CODEBASE
One codebase tracked in SCM, many deploy
DEPENDENCIES
Explicitly declare isolate dependencies
CONFIGURATION
Store config in the environment
BACKING SERVICE
Treat backing service as attached resources
BUILD, RELEASE, RUN
Strictly separate build and run stages
PROCESSES
Execute app as stateless processes
PORT BINDING
Export services via port binding
CONCURRENCY
Scale out via the process model
DISPOSABILITY
Maximize robustness & graceful shutdown
DEV/PROD PARITY
Keep dev, staging and prod as similar as possible
LOGS
Threat logs as event stream
ADMIN PROCESSES
Run admin/management tasks as one-of processes

Inter-service Communication

Synchronous Communication

Rest API (Richardson Maturity Model)
REST is primarily used over HTTP and it makes use of HTTP GET, POST, PUT, DELETE and PATCH methods for different CRUD operations.

Asynchronous Messaging Styles

Single Receiver

Single receiver based asynchronous communication with AMQP
Example : RabbitMQ or ActiveMQ

Multiple Receivers

Example : Kafka

Handling Transactions in Monolithic Architecture

Transaction Control

If a user sends a Checkout request to the platform, the platform will create a local database transaction that works over multiple database tables, to Process the order and Reserve items from the inventory. If any step fails, the transaction can roll back, both the order and items reserved.

This is known as ACID (Atomicity, Consistency, Isolation, Durability), which is guaranteed by the database.

Handling Distributed Transactions in the Microservice World

Eventual Consistency and Compensation / SAGA

One of the best definitions of eventual consistency, is described on microservices.io:

Each service publishes an event whenever it updates its data. Other service subscribe to events. When an event is received, a service updates its data.

In this approach, the distributed transaction is fulfilled by asynchronous local transactions on related microservices. The microservices communicate with each other through an event bus.

Eventual Consistency and Compensation / SAGA — Success Scenario

Eventual Consistency and Compensation / SAGA — Failed Scenario

Pros and Cons of Eventual Consistency and Compensation / SAGA

Pros:
- Atomic Transaction
- No database lock required
- Highly scalable during heavy load

Cons
No read-write isolation ( In the above example the client could see the order was created, but in the next second, the order is removed due to a compensating transaction.)