The document discusses various data patterns for microservices including using a shared database, separate database patterns, and the strangler pattern. It notes that while a shared database may be necessary for brownfield conversions of monolithic applications, it is an anti-pattern for microservices as it can introduce dependencies between teams. For greenfield projects, a separate database pattern is recommended where each microservice has its own database. The strangler pattern is presented as a way to transition existing monolithic applications with a shared database to microservices over time by adding API/services and eventually replacing the legacy components.

1. http://acloudfan.com/
Pragmatic Paths Inc © 2021
Contact: raj@acloudfan.com
Discount Link to course:
https://www.udemy.com/course/domain-driven-design-and-microservices/?referralCode=C5DCD3C4CC0F0298EC1A
Section: Microservices Data Patterns
Course: Domain Driven Design & Microservices for Architects

2. www.ACloudFan.com
Microservices Data Patterns
Domain Driven Design
Databases are an essential part of ALL applications.
B
A
C

3. Microservices Data Patterns
Monolithic app to Microservices
B
A
C

4. Microservices Data Patterns
Breaking the Database is a CHALLENGE

5. Microservices Data Patterns
Data Patterns
• Used for designing the new Microservices
• Conversion of Monolithic apps to Microservices

6. Microservices Data Patterns
1 Shared Database Pattern
2 Separate Database Pattern
3 Strangler Pattern
4 Converting monolith to microservices
5 Options for breaking shared DB into multiple DB instances
Section objective

7. Data storage in legacy applications
*
Persistence in Shared Databases
1 Shared Database pattern
2 Pros of shared database
3 Cons of shared database

8. Data Storage
Persistence for application data
• Managed in raw files
• Databases
Relational DBs commonly used in legacy apps for all types of data !!

9. Use of RDBMS in Legacy Apps
Shared Database(s) for multiple applications
Enterprise
Applications
Shared Database
SQL Statements
SQL Statements
SQL Statements

10. Shared Database - Good things
2 Cost savings on Database (licensing, servers …)
3 Centralized database administration
1 Simplified data management

11. Challenges with Shared Database
1 DB Changes need to be managed carefully
All application owners will need to assess the impact on their App !!!
• High Cost
• High Risk
• Longer time to value
Application A needs a change in Schema

12. Challenges with Shared Database
2 One application may negatively impact all applications
One App can use too much resource and impact all other Apps !!
A
B
C
OLAP
E.g., Large Batch Job
• Impact on other applications
Uses up connections | resources on Database

13. A
B
C
Challenges with Shared Database
3 Single Point of Failure
All Applications dependent on the DB will be unavailable !!!
• Complex HA solutions à High cost
A failure here means all applications down

14. Challenges with Shared Database
4 Capacity planning for the Database
ALL teams MUST provide estimates on their usage !!!
CPU | Memory | Storage
OVER Capacity is Common !!!
A
B
C

15. Challenges with Shared Database
6 Same Database types for all applications
Application teams does not have a choice of DB type !!!

16. Monolithic applications
Shared Database(s) is an anti-pattern BUT
• Many enterprises are still dealing with such applications
• Service Oriented Architecture | API for rescue
S
O
A

17. Quick Review
Shared Database(s) is an anti-pattern BUT
• Many enterprises are still dealing with such applications
• Service Oriented Architecture (SOA) | API for rescue
S
O
A

18. Insulated applications from underlying database(s)
*
Service Oriented Architecture (SOA)
1 Introduction to SOA
2 SOA & Shared Database pattern
www.ACloudFan.com

19. Service Oriented Architecture
Data exposed by way of CRUD services | API
CREATE
RETRIEVE
UPDATE
DELETE
Hides the Database structure behind services !!!

20. SOA Layer placed between Apps & DB
Shared Database
SQL Statements
SQL Statements
SQL Statements
A
B
C
www.ACloudFan.com

21. SOA Layer placed between Apps & DB
Shared Database
SOA
Services
Layer
Services provided CRUD and Higher-level business operations
Svc
Svc
Svc
A
B
C
HTTP/MQ XML/JSON SOAP/REST

22. SOA addressed some Challenges
1 Hides the structure of DB i.e., no more SQL statements
2 Services were designed to be re-usable
Doesn't address *many* of the shared DB challenges !!
3 Changes to DB become manageable

23. Misconception
A small SOA Service is a Microservice

24. Misconception
A small SOA Service is a Microservice
NOT a Microservice

25. Quick Review
SOA services insulated the application from Database changes
• BUT did not address other challenges of Shared Database(s)
www.ACloudFan.com

26. Recommended for Greenfield Microservices Initiative
*
Separate Database Pattern
1 Greenfield versus Brownfield
2 Separate Database Pattern
3 Advantages of separate DB

27. Microservices Projects
Brownfield
Existing monolithic app to be converted to Microservices architecture
Greenfield
New application with no constraints from technical debt perspective

28. Microservices : Recommendation
Brownfield
"Separate DB" recommended for Microservices
Is it even possible to break the existing DB?
Is it worth the effort i.e., do a Cost-Benefit Analysis?
What will be the Business benefits?
www.ACloudFan.com

29. Microservices : Recommendation
Greenfield
"Separate DB" recommended for Microservices
Are the teams skilled for managing their own DB?
Does the organization have tools to manage multiple database?
Are the teams ready to manage design complexities?
www.ACloudFan.com

30. Microservices from ground up
Greenfield
Microservices teams assigned the Bounded Context
DDD Exercise

31. Microservices from ground up
Each microservice has its own Database !!!
Greenfield
A
B
• No interdependency between teams
• Each team decide on their tech stack
• Service interactions via defined interfaces
• No direct access to data

32. Under Maintenance
NO Direct Impact
Benefits : Separate Database Pattern
A
B
C
Simpler change management

33. Separate Database Pattern
Each microservice team owns & manages their database
A
B
C

34. Benefits : Separate Database Pattern
Reduced blast radius on Database Failure
NO direct impact on B & C
A

35. Benefits : Separate Database Pattern
Capacity planning | Scaling at DB level becomes simpler
• No new capacity for next year
• Additional 5 TB for storage
• 1 TB Storage • CPU +2 cores

36. Benefits : Separate Database Pattern
Each team can decide on Database i.e., doesn't have to RDBMS
• RDMBS
• NoSQL
• RDBMS

37. Quick Review
Separate Database Pattern is recommended
Greenfield

38. Converting a Monolith to Microservices
*
Brownfield & Databases
1 Converting Brownfield to Microservices
2 Shared Database = Anti pattern
3 Strangler pattern

39. Shared
Database
Conversion to Microservices
Brownfield
A monolith is refactored to multiple microservices
2 Database Refactoring
1 Apply Separate DB Pattern
3 Logical separation of database

40. Conversion to Microservices
Brownfield
A monolith is refactored to multiple microservices
1 Apply Separate DB Pattern
Using the Strangler Pattern
www.ACloudFan.com

41. Conversion to Microservices
Brownfield
A monolith is refactored to multiple microservices
System of records in RDBMS
• Hundreds of tables • Complex relationships
• Stored Procedures | Triggers

42. A
B
C
Microservices will suffer from the same challenges as applications !!!
Conversion to Microservices
Brownfield
ONLY application refactored; DB stays in place

43. Shared Database Pattern
It is an Anti-Pattern as it leads to inter-dependencies
A B C
DB Administration Team
• Slow speed to value
• Increased testing effort
• Higher need for coordination
• No independent scaling

44. Shared DB : Transition State Architecture
Positioning the application for Microservices architecture
Transition
State
Target
State
• Focus on Application
• Focus on Data

45. Shared DB : Transition State Architecture
Keep the Microservices code independent of the Database
A
B
C
Use of SQL in code will make it difficult to switch the DB !!!
SQL Statement

46. Strangler Strategy
Access the data via services/API in the transition stage
A
B
C
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Switching the DB will not affect the Microservice
Strangler services | Stranglers

47. Strangler Strategy
Access the data via services/API in the transition stage
A
B
C
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Teams decide their priorities and work independently (almost)

48. Strangler Strategy
Access the data via services/API in the transition stage
A
B
C
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Svc
Eventually the target state is achieved !!!

49. Strangler Pattern
May be used for other legacy services as well
A
Svc
Svc
Svc
Legacy Services
Modernized Services

50. Strangler Pattern
Over a period, modernized service will replace the legacy service
A
Svc
Svc
Svc
Legacy Services
Modernized Services

51. Strangler Pattern
The strangler services will be changed to point to new services
A
Svc
Svc
Svc
Modernized Services
Microservice code insulated from backend changes !!!

52. Quick Review
Shared Database pattern = Anti pattern for Microservices
Strangler pattern used for replacing the backend | databases
Target
State

53. Converting Brownfield monolith to Microservices
*
Microservices : Shared DB Pattern
1 Objective & Challenges
2 Database Refactoring
Note: Discussion apply ONLY to an RDBMS
3 Logical Database Separation

54. Reality check
One may not have the flexibility of using "Separate DB"
• Time constraints • Cost | Budget constraints
For multiple reasons:
• Lack of skilled resources • Higher risk
• Legacy technology • …
Brownfield

55. Objective
Achieve isolation of data within the same Database instance
• Each Microservice owns part of the data in the Database
• Each Microservice have direct access to ONLY its own data
Use DB features to achieve MAXIMUM isolation between Microservices

56. Challenges with breaking the DB
A
B
C
Large Databases are NOT easy to separate L
Brownfield

57. Challenges with breaking the DB
Separation doesn't end with segregating the tables
• Shared data across Microservices
• Relationships between tables
• Stored Procedures
• Triggers
Brownfield
www.ACloudFan.com

58. Dealing with Shared Database
1 Database Refactoring
2 Logical separation of database
• Changes to underlying database
• Use the database as-is

59. A small change to the database which
improves its design without changing its
semantics
by Scott W & Pramod S
Database Refactoring
1

60. Structural Changes to definition of tables, views, and columns
Architectural Changes to methodology on how apps interact with DB
Referential
Integrity
Changes to the Primary Key, Foreign Keys, Triggers
There are 6 change categories suggested for DB Refactoring
Database Refactoring
1

61. Methods
Code changes to Stored Procedure like adding and
removing parameters
Transformations Changes to the database schema
Data Quality Changes for improvement to data quality
There are 6 categories of change suggested for DB Refactoring
Database Refactoring : Change Categories
1

62. Example : Structural Refactoring
Schema A
Schema B
Schema C
Separate schemas and put in access control for microservices
How is it done? Depends on the specific RDBMS !!!!

63. Tables owned by
Microservice A
Logical separation of the Database (RDBMS)
2
Divide the related tables among Microservices
Teams need to be disciplined; not to access other MS data directly
Tables owned by
Microservice B
Tables owned by
Microservice C

64. Using services for data access
All data access via services to minimize risk of direct access
• Governed services
• Provides control over only the assigned tables/data
Logically
separated DB
Table: A, B, C, D, E
Table: P, Q, R, S
Table: X, Y, Z

65. Quick Review
Microservices
Initiative?
Greenfield Brownfield
Separate DB Pattern
Break the DB
DB Refactoring
DB Design Changes
Evaluate
Time/Cost/Resource/Risk/
Complexity
Analyze DB
Technology, Complexity,
Data, Skills …
Logical Separation
NO DB Changes

66. But there are solutions !!!
*
Downside of Separate Databases
1 Challenges
2 Solution to challenges
3 Introduction to CQRS, Event Sourcing & SAGA patterns

67. Downside : Separate Database Pattern
1 HIGHER cost of the Database for the solution
$$$ spent on Databases may go up by up to 3 times !!
Licensing | Hardware
Operational | Maintenance

68. Downside : Separate Database Pattern
2 Degraded Read Performance due to distribution of data
A
API
API
B
C
In a Shared DB - we could have used a JOIN !!!
GET data from A
GET data from B
Merge data from A & B
SQL Statement
SQL Statement

69. Addressing the challenge
Manage local copy of the data thru asynchronous replication
B
A
Data from B
(as a view)
CQRS & Event Sourcing patterns
<<Event Source>>
<<Event Consumer>>
SQL INSERT/UPDATE/DELETE
I Event
SQL INSERT/UPDATE/DELETE
API
Change Data for B
API
Query data for A& B
Local SQL Query

70. Downside : Separate Database Pattern
3 Complexity in managing Transaction | Data integrity
Shared DB - Could have used a local Transaction !!!
Customer
PAID + Received Email
but will not receive the
order L
Shipment
Orders
Thanks for
your order
!!!
Notifier
2. Ship the Order FAILED
1. Inform Customer SUCCESS

71. Addressing the challenge
Use a sequence of local transactions with distributed rollback
B
C
Local TX Local TX
A B

72. Addressing the challenge
Use a sequence of local transactions with distributed rollback
Rollback changes to DB
SAGA & Reliable messaging pattern
B
C
FAILED Local TX
A B

73. Quick Review
CQRS Pattern & Event Sourcing
Open Source, Cloud Native Databases
SAGA Pattern & Reliable messaging
www.ACloudFan.com