Microservice Database
No-SQL DB
Relational DB
Stores data into related data tables
has fixed schema and use SQL to manage data
supports Transaction with ACID
data is normalized
unstructured data is stored here
stored in Key-Value Pairs or JSON Documents
don't provide ACID guarantees. Thus, Transactions cant be possible
No-SQL Document DB
Store and Query data in JSON Doc
Data and metadata are stored hierarchically
Objects are mapping to application code
Easily scalable. Content Mgmt and storing catalogs, MongoDB and Cloudant
No-SQL Key-Value DB
Stored as collection in Key-Value pairs
Session oriented applications e.g., Storing customer basket data
Redis, Amazon DynamoDB, Oracle NoSQL DB
No-SQL Column-Based DB
Wide-Column DB
Data is stored in Columns
Data Ware House and Big data processing
Apache Cassandra, HBase or DynamoDB
No-SQL Graph based DB
Stores Data in graph structure
Data Entities are connected by Nodes
Fraud Detection, Social Networking and Recommendation engines
OrientDB, Neo4j, Amazon Neptune
How to Choose DB for Microservice
Consistency Level
Helps in scalability and High Availability. e.g., CQRS
Strict Consistency
Eventual Consistency
Banking. you want to see same data at real-time everywhere
All DB Copies are updated immediately.
Social Networking or you tube video likes
Prefer Relational DB
Highly Scalable
High Availability
CAP Theorem helps us in deciding the DB
CAP Theorem
Consistency, Availability and Partitioning
only CA, CP or AP can be achieved
Consistency
Ensures the read value is the latest and updated one
if the value isn't the latest, then block the Request till replicas update.
Availability
ability to respond to requests at any time
fault-tolerance in order to accommodate all requests. System remains operational all the time
Partitioning
Network Partitioning, parts of system are located in different networks
All Clients see the same view of data, even right after update or delete
click to edit
All clients can find a replica of data, even in case of partial node failures
The system continues to work as expected, even in presence of partial node failure
Partition Tolerance is must for Distributed Architecture
Microservice Architectures choose Partition Tolerance with High Availability and follow eventual Consistency
Partitioning
Horizantal Partitioning or Sharding
All partitions have same Schema. Data is distributed on Partitions
Cassandra No-SQL DB is best example. It has the Nodes and all nodes are connected. Works as Master-less Architecture.
Vertical Sharding
Does Row Splitting
Columns of table are distributed on partitions. Frequently accessed columns
Functional Partitioning
Partition data based on bounded context or sub-domain
Data is segregated according to use of Bounded Context
Sharding is the process of dividing the DB into small units
DB Patterns
Materialized View Pattern
CQRS Pattern
Microservice can create a denormalized data for quick access. e.g., product and price details. This saves time needed to fetch details from another service. Whenever data is updated in actual DB, use Event driven arch to update values of denormalized data
Command and Query Responsibilities Segregation
Read and Write DB's are separate and managed by Eventual or Strict consistency
uses PostgreSQL Relational and Cassandra No-SQL. RabbitMQ and Django (python). Cassandra is enabled with auto-sharding feature. used feeds and messaging data is stored in No-SQL
Event-Sourcing Pattern
The write operations/Events are stored on the Event Store DB. Which are published to Event Bus and eventual consistency is followed to update the DB.
These Events on Event Store act as source of truth for the data
Transactions
Microservice Distributed Transaction
Transaction should be handled separately in a distributed DB env
Rollback should be initiated on multiple DB's when required
Saga Pattern
Coreography
All services are connected on Message Broker and all services perform db activity and report back to Broker. Final Update is performed based on the responses.
Orchestration
Centralized service will control the transaction
Single-point of failure
Outbox Pattern
Create a table called Outbox. Whenever Transaction is complete, add record to outbox in same transaction. Publish this to message broker using a service.
click to edit