The document discusses microservices and some of the challenges of moving to a microservices architecture. It describes what microservices are and how decomposing an application into loosely coupled services can help deliver changes rapidly and reliably. However, distributing an application in this way introduces challenges around distributed data, consistency, and event-driven messaging. Patterns like sagas, event sourcing and CQRS are discussed as ways to help maintain consistency when data is distributed across multiple microservices.

1. Microservice
17 Media
Viney Shih, Sr. Engineering Manager

4. Agenda
● What’s Microservice and the relation with organization
● What’s the challenge moving to Microservice
● Distributed data
● Event-driven messaging
● Consistency
● Summary
● Q&A

5. What’s Microservice

6. When to Microservice

7. Reference: https://andrebartholomeufernandes.com/why-
software-is-eating-the-world/
In the future, every company will become a software company

8. Deliver software rapidly, frequently and reliably
● Velocity
● Lead time: time from commit to deploy
● Deployment frequency: deploys per developer per day
● Reliability
● Change failure rate: % of deployments that cause an outage
● Mean time to recover from a deployment failure

9. Needs to able to easily modernize applications
● Successful applications often lives a very long time
● Technology changes

10. Success Triangle
Deliver changes
to long-lived
applications
rapidly, frequently and reliably
Process
ArchitectureOrganization

11. Success Triangle
Deliver changes
to long-lived
applications
rapidly, frequently and reliably
Process: SRE, CI / CD, Automation
Architecture: ???Organization: Autonomous team

12. ● SRE
(DevOps)
● Autonomous team
● Long-lived
applications
Required architectural quality attributes (.a.k.a ilities)
● Testability
● Deployability
● Maintainability
● Modularity
● Evolvability

13. Monolithic architecture

14. Ilities of small monoliths
● Testability ✅
● Deployability ✅
● Maintainability ✅
● Modularity ✅
● Evolvability ✅

15. But when keep growing …
Development Team Application

16. Keep growing …
ApplicationDevelopment Team

17. Keep growing …
Development Team
ApplicationDevelopment Team
Development Team

18. Reference: http://www.laputan.org/pub/foote/mud.pdf

20. Rapid, frequent and reliable delivery eventually becomes impossible
Maintainability
Testability
Deployability
Modularity
Evolvability
Time (Size complexity)
Ilities required to be competitive
Risk of disruption

22. The Scale Cube
Reference: https://akfpartners.com/growth-blog/scale-cube

23. Y axis scale

24. X-Z axis scale
Main Structure Replica set

25. Homework
● What’s X-Y axis scale?
● What’s X-Y-Z axis scale?

26. The microservice architecture is an architectural style that
structures an application as a set of loosely coupled services

27. Each Microservice is
● Highly maintainable and testable
● Loosely coupled (e.g. database)
● Independently deployable
● Organized around business capabilities
● Owned by a small team

28. Order Service
Customer Service
Product Service
Notification Service

29. Benefits of Microservice
Deliver changes
to long-lived
applications
rapidly, frequently and reliably
Process: SRE, CI / CD, Automation
Architecture: microserviceOrganization: Small, Cross-function,
autonomous teams
Testability
Deployability
Maintainability
Modularity
Evolvability
Modularity

30. Drawbacks of microservice: Complexity
● Development: IPC, consistency, partial failure, distributed data
● Testing: integration, end to end, …
● Infra: monitoring, deploy, …
● Correctly identifying service boundaries → bounded context
● Refactoring a monolithic application to a microservice architecture

31. Challenge I: How to apply it into domain model?
● Object points to one to another.
Order
*Customer
Address
City
Street
OrderItem
Quantity
*Product
Customer
CreditLimit
Product
Price
Name

32. Challenge II: How to implement ACID transaction?
BEGIN TRANSACTION
…
SELECT OrderTotal FROM Orders WHERE CustomerID = ?
…
SELECT CreditLimit FROM Customers WHERE CustomerID = ?
…
INSERT INTO Orders …
…
COMMIT TRANSACTION

34. Domain-Driven Design (.a.k.a DDD)
● Entity
● Value Object
● Services
● Repositories
● Aggregates

35. Aggregate
● Cluster of objects that can be treated as a unit
● Graph consisting of a root entity and one or more other entities and value
objects.

36. Aggregate (cont.)

37. Aggregate: rule #1
● Reference other aggregate roots via identity.
● Domain model → collection of loosely connected aggregates
Order
customerID
Address
City
Street
OrderItem
Quantity
productID
Customer
CreditLimit
Product
Price
Name

38. Aggregate: rule #2
● Process one command by one aggregate.
● Aggregate scope = Transaction scope → Service
Order
customerID
Address
City
Street
OrderItem
Quantity
productID
Customer
CreditLimit
Product
Price
Name
Order Service Customer Service
Product Service

39. Aggregate granularity
● If an update must be atomic, it must be handled by a single aggregate.
● Granularity leads different consistency and scalability
Customer
Order
Product
Customer
Order
Product
Order
Customer
Product
Consistency Scalability

40. Two-Phase Commit (.a.k.a 2PC) is not a viable option
● Guarantees consistency
● Not supported by many NoSQL and MQ
● Impacts availability in CAP Theorem
● …

41. SAGA pattern from a 1987 paper

42. How do the saga participants communicate?
● Synchronous (e.g. REST, gRPC, …)
● Availability(N) = Availability(N1)
x Availability(N2) x
Availability(N3) x …
● Recovering mechanism: retry
Order
Service
Customer
Service
createOrder()POST /order
reseveCredit()PUT /customer/id/credit

43. ● Collaboration using asynchronous, broker-based messaging
● eventual consistency
● At least once delivery
● Ordered delivery
● Availability(N) = Availability(N1)
Order
Service
Customer
Service
createOrder()POST /order
reseveCredit()
Message Broker

44. Two patterns
● Choreography: distributed decision making
● Orchestration: centralized decision making

45. Choreography-based Saga
Status: Pending / Created / Rejected
DB

46. Choreography-based Saga (cont.)

47. Benefits and drawbacks of Choreography
● Benefits
● Simple
● Participants are loosely
coupled
● Drawbacks
● Decentralized implement: difficult
to understand
● Cyclic dependencies
● …

48. Orchestration-based Saga

49. Orchestration-based Saga (cont.)

50. Benefits and drawbacks of Orchestration
● Benefits
● Centralized coordination
logic is easier to
understand
● Reduce cyclic
dependencies
● Simplified the business
logic
● Drawbacks
● smart orchestrator tells dumb
services what to do

51. Homework
● Synchronous RESTful API initiates asynchronous SAGA
● Rollback strategy
● SAGAs are ACD → No Isolation

52. How atomically update database and publish an event?
● Dual write problem
Service
Database
Message
Broker
❓
❓

53. Data consistency in event-driven architecture
● Application events (Transactional outbox):
● eBay
● one transaction two tables, and one app polling

54. ● Transaction log tailing:
● LinkedIn
● polling transaction log
● MySQL binlog
● Postgres WAL
● AWS DynamoDB
table streams
● MongoDB change
streams

55. ● Event Sourcing:
● Persists an object as a sequence of events
View
id: 123
author: Jane Doe
impact: 10

56. Benefits and drawbacks of Event Sourcing
● Benefits
● Solve data consistency
● Preserve history → replay
whole data
● Support temporal queries
● Simplify retroactive
correction
● Built-in auditing
● Drawbacks
● Unfamiliar programming model
● Evolving the schema of long-lived
events
● Only supports PK-based access
→ CQRS

57. Command and Query Responsibility Segregation (.a.k.a CQRS)
● Using events to
update a
queryable
replica.

58. Summary
● Microservice enables whole business, team and architecture
● Data is distributed which create challenges
● Use event-driven architecture for eventual consistency
● Use Sagas to maintain data consistency across service
● Understand Event Sourcing and CQRS

59. Q & A
Thanks for your Time!