scaling with demand of each microservice is not good since shared need to be scaled even though only one microservice has high demand
same table might be used by different microservices, hence modification can cause issues
shared DB advantages:
JOINs are easily handled
transactions are easily handled (ACID)
assume I need to insert into 10 tables, then I can perform transaction easily and in case of failure can rollback
DBs per service
SAGA pattern helps perform transactions (ACID)
CQRS pattern helps distributed DBs perform JOINs
Sidecar Pattern
aka Sidekick pattern
Resembles a sidecar attached to a motorcycle.
Deploy components of an application into a separate process or container to provide isolation and encapsulation.
Provides supporting features for the parent application
Shares the same lifecycle as the parent application (creation, deletion)
Examples
Infrastructure API
Infrastructure team creates a service alongside each application which performs logging, environment data, configuration store, discovery, health checks, and watchdog services
the sidecar also monitors parent application’s host environment and process and logs the information to a centralized service
Instead of storing just the current state of the data in a relational database, store the full series of actions taken on an object in an append-only store.
Command Handlers
Calls the event store to get the historical events for the entity
Events are played back in the object to materialize the current state of the entity
The business logic is run and events are raised
It is relatively expensive to read and replay events
applications typically implement materialized views
Often combined with CQRS Pattern
Advantages
Events are immutable and can be stored using an append-only operation
Can help prevent concurrent updates from causing conflicts because it avoids the requirement to directly update objects in the data store
Provides an audit trail to monitor actions taken on entity
Disadvantages
It is complex to implement and should be avoided
Eventual Consistency
Current state of an entity can be determined only by replaying all of the events
Consumers must be idempotent to avoid re-applying same update
Examples
Bulkhead Pattern
aka cell-based architecture
Named after the sectioned partitions (bulkheads) of a ship’s hull
If the hull of a ship is compromised, only the damaged section fills with water, which prevents the ship from sinking
Application design that is tolerant of failure
Elements of an application are isolated into pools so that if one fails, the others will continue to function
Partition service instances into different groups, based on consumer load and availability
Consider deploying them into separate VMs, containers, or processes.
asynchronous messages can be isolated through different sets of queues
Each queue can have a dedicated set of instances
Messaging Bridge Pattern
Integrate disparate systems that are built on top of different messaging infrastructures
old system with old message queue <-----> message bridge <----> new msg queue <---> new system
Blue-Green Deployment
Two identical environments, referred to as “blue” and “green,” are set up.
One environment (blue) is running the current application version and one environment (green) is running the new application version.
Once green environment is tested, the live traffic is directed to it, and the blue environment is used to deploy a new application version during next deployment cycle.
Reduces the risk associated with deploying new versions of an application
