- Microservices advocate creating a system from small, isolated services that each own their data and are independently scalable and resilient. They are inspired by biological cells that are small, single-purpose, and work together through messaging. - The system is divided using a divide and conquer approach, decomposing it into discrete subsystems that communicate over well-defined protocols. Each microservice focuses on a single business capability and owns its own data and behavior. - Microservices communicate asynchronously through APIs and events to maintain independence and isolation, which enables continuous delivery, failure resilience, and independent scaling of each service.

1. Microservice Architecture
Design Principles
Sanjoy Roy
sanjoykr78@gmail.com

2. Let’s take the inspiration from biological
cells before talking about Microservice:
• They are small and single purpose
• They are many of them but they work in
concert with one another
• Each cell is able to respond to its
environment
• They communicate with each other using
messages
• They can replicate
• They keep outside out
• Death is natural and expected

3. Microservice architecture
advocates creating a system from
a collection of small, isolated
services, each of which owns their
data, and is independently
isolated, scalable and resilient to
failure.

4. Divide and Conquer
A divide and conquer algorithm works by
recursively breaking down a problem into two
or more sub-problems of the same (or
related) type (divide), until these become
simple enough to be solved directly
(conquer). The solutions to the sub-problems
are then combined to give a solution to the
original problem.

5. In Microservice Architecture we use
Divide and Conquer:
the decomposition of the system into
discrete and isolated subsystems
communicating over well-defined
protocols.

6. Microservice
Single Responsibility Replaceable
Organized around business
capabilities

7. Single Responsibility Principle
Single Responsibility Principle (SRP)
states that a class or component should
“only have one reason to change.”

8. Do One Thing, and Do It Well
This is the Unix philosophy: Write
programs that do one thing and do it well.
Write programs to work together.
—Doug McIlroy

9. “Micro” should refer to scope of
responsibility.
A service has only one single reason to
exist and should provide a single
composable piece of functionality.

10. A service should do one thing
and do it well.
Focus should be on business capability.

11. What about state?
Microservices are often stateful
entities:
they encapsulate state and behavior.

12. Product
Service
Customer
Service
Order
Service
Payment
Service
Search
Service
DB
This is still a monolith.

13. Oracle Couchbase Oracle
Customer
Service
Customer
Service
Customer
Service
Customer
Service
Product
Service
Product
Service
Product
Service
Product
Service
Order
Service
Order
Service
Order
Service
Bounded Context Bounded Context Bounded Context
A microservice owns its data.
Business Capability Business Capability Business Capability

14. Decentralized Data Management
• Each microservice manages it’s own database: either different
instances of same database technology or completely different
database system (polyglot persistence)
• Eventual consistency

15. Microservices encapsulate state and behaviour.
Model each service as a Bounded Context.
Each service usually defines its own domain, each with
its own Ubiquitous Language.
State
(Data)
Behaviour
(Business Rules)
Business Capability

16. Search
Service
Search
Service
Search
Cache Couchbase
Product
Service
Product
Service
Product
Service
Product
Service
Bounded Context
Bounded Context
Client
Business Capability Business Capability

17. Isolation
Isolation is a prerequisite for resilience and elasticity
Embrace Share Nothing Architecture
Failure Isolation (Bulkheading)
Isolation between services makes it natural to adopt Continuous
Delivery
Isolation also makes it easier to scale each service, as well as
allowing them to be monitored, debugged and tested
independently
Isolation is a prerequisite for autonomy

18. An autonomous service can only promise its own behaviour by
publishing its protocol/API.
All information needed to resolve a conflict or to repair under
failure scenarios are available within the service itself, removing
the need for communication and coordination.
APIs need to be well-defined and composable.
Autonomous Service

19. Communicate through APIs
Service B
Couchbase
Service A
Oracle
API
invoke expose
Contract
Shared
understanding

20. API Client/Server Guidelines
 REST level-3 with HAL+json
 Use proper HTTP techniques
 Base design on application states and transitions
 Forward compatibility over versioning
 Drive documentation from code
 Don’t write smart clients

21. Autonomy through Messaging
Service A
(Pub)
Service B
(Sub)
Service C
(Sub)
Message Bus1 2 3

22. • Only publish business events and IDs – avoid mutable
data
• Implement proper error handling
• Beware of added complexity
Message Publisher Guidelines

23. • Cater for duplicate message delivery through
idempotency
• Don’t rely on ordering
• 1C late-commit pattern over 2PC
• Implement proper error handling
• Beware of added complexity
Message Receiver Guidelines

24. Microservice benefits
• Strong module boundaries
• Independent deployment
• Technology diversity
• Failure isolation
• Improves time to market
• Reduced cost of change
and costs
• Distribution
• Eventual consistency
• Operational complexity

25. General Microservice Architecture Principles
• Small and focused on a specific business capability
• Eventual consistency
• availability is more important than global and instant consistency
• Polyglot persistence
• Pick most appropriate data and consistency model
• Async communication over sync
• Failure resilient
• Avoid SPOFs

26. Thank you