Scribd
Upload
89 views

Microservice Patterns

Uploaded by

sharan kommi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
89 views

Microservice Patterns

Uploaded by

sharan kommi
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 8

Microservice Patterns

1. Shared Database
Use a (single) database that is shared by multiple services. Each service
freely accesses data owned by other services using local ACID transactions.

Advantages:

 A developer uses familiar and straightforward ACID transactions to


enforce data consistency
 A single database is simpler to operate

Issues:
 Runtime coupling - because all services access the same database they
can potentially interfere with one another

 Single database might not satisfy the data storage and access
requirements of all services.

2. Database per Service


The service’s database is effectively part of the implementation of that
service. It cannot be accessed directly by other services.

There are a few different ways to keep a service’s persistent data private.
You do not need to provision a database server for each service. For example,
if you are using a relational database then the options are:

 Private-tables-per-service – each service owns a set of tables that must


only be accessed by that service
 Schema-per-service – each service has a database schema that’s
private to that service
 Database-server-per-service – each service has it’s own database
server.

Private-tables-per-service and schema-per-service have the lowest overhead.


Using a schema per service is appealing since it makes ownership clearer.
Some high throughput services might need their own database server.

It is a good idea to create barriers that enforce this modularity. You could, for
example, assign a different database user id to each service and use a
database access control mechanism such as grants. Without some kind of
barrier to enforce encapsulation, developers will always be tempted to bypass
a service’s API and access it’s data directly.
Example: The FTGO application is an example of an application that uses
this approach. Each service has database credentials that only grant it
access its own (logical) database on a shared MySQL server.

Advantages:
 Helps ensure that the services are loosely coupled. Changes to one
service’s database does not impact any other services.

 Each service can use the type of database that is best suited to its
needs. For example, a service that does text searches could use
Elasticsearch. A service that manipulates a social graph could use
Neo4j.

Issues:
 Implementing business transactions that span multiple services is not
straightforward.

 Implementing queries that join data that is now in multiple databases is


challenging.

 Complexity of managing multiple SQL and NoSQL databases

Solutions:
 Implementing transactions that span services - use the Saga pattern.

 Implementing queries that span services:

o API Composition - the application performs the join rather than


the database. For example, a service (or the API gateway) could
retrieve a customer and their orders by first retrieving the
customer from the customer service and then querying the order
service to return the customer’s most recent orders.

o Command Query Responsibility Segregation (CQRS) - maintain


one or more materialized views that contain data from multiple
services. The views are kept by services that subscribe to events
that each services publishes when it updates its data. For
example, the online store could implement a query that finds
customers in a particular region and their recent orders by
maintaining a view that joins customers and orders. The view is
updated by a service that subscribes to customer and order
events.

3. CQRS - Command Query Responsibility


Segregation
How to implement a query that retrieves data from multiple services in a
microservice architecture?
Define a view database, which is a read-only replica that is designed to
support that query. The application keeps the replica up to data by
subscribing to Domain events published by the service that own the data.

Domain events are events generated on updating and creating certain data.
These events are consumed by other services.

Advantages:

 Supports multiple denormalized views that are scalable and performant


 Improved separation of concerns = simpler command and query models
 Necessary in an event sourced architecture

Issues:

 Increased complexity
 Potential code duplication
 Replication lag/eventually consistent views

4. Saga
How to implement transactions that span services?

Implement each business transaction that spans multiple services is a saga.


A saga is a sequence of local transactions. Each local transaction updates
the database and publishes a message or event to trigger the next local
transaction in the saga. If a local transaction fails because it violates a
business rule then the saga executes a series of compensating transactions
that undo the changes that were made by the preceding local transactions.
There are two ways of coordination sagas:

 Choreography - each local transaction publishes domain events that


trigger local transactions in other services
 Orchestration - an orchestrator (object) tells the participants what local
transactions to execute

Advantages:

 It enables an application to maintain data consistency across multiple


services without using distributed transactions

Issues:

 The programming model is more complex. For example, a developer


must design compensating transactions that explicitly undo changes
made earlier in a saga.

5. Circuit Breaker
When one service synchronously invokes another there is always the
possibility that the other service is unavailable or is exhibiting such high
latency it is essentially unusable.

Precious resources such as threads might be consumed in the caller while


waiting for the other service to respond.
This might lead to resource exhaustion, which would make the calling
service unable to handle other requests. The failure of one service can
potentially cascade to other services throughout the application.

How to prevent a network or service failure from cascading to other services?

A service client should invoke a remote service via a proxy that functions in a
similar fashion to an electrical circuit breaker.

When the number of consecutive failures crosses a threshold, the circuit


breaker trips, and for the duration of a timeout period all attempts to invoke
the remote service will fail immediately.

After the timeout expires the circuit breaker allows a limited number of test
requests to pass through. If those requests succeed the circuit breaker
resumes normal operation. Otherwise, if there is a failure the timeout period
begins again

Advantages:

 Services handle the failure of the services that they invoke

Issues:

 It is challenging to choose timeout values without creating false


positives or introducing excessive latency.

6. Client-side Service Discovery


 Each instance of a service exposes a remote API such as HTTP/REST,
or Thrift etc. at a particular location (host and port)
 The number of services instances and their locations changes
dynamically.
 Virtual machines and containers are usually assigned dynamic IP
addresses.
 The number of services instances might vary dynamically. For example,
an EC2 Autoscaling Group adjusts the number of instances based on
load.

How does the API gateway discover the location of a service instance?

When making a request to a service, the client obtains the location of a


service instance by querying a Service Registry, which knows the locations
of all service instances.

Service Registry: Database of services, their instances and their locations.


Service instances are registered with the service registry on start-up and
deregistered on shutdown. A service registry might invoke a service
instance’s health check API to verify that it is able to handle requests
Issues:

 This pattern couples the client to the Service Registry


 You need to implement client-side service discovery logic for each
programming language/framework used by your application

Service-side discovery: Example- AWS Load balancer

Lambda Architecture
Aim: To satisfy the needs for a robust system that is fault-tolerant, both
against hardware failures and human mistakes, being able to serve a wide
range of workloads and use cases, and in which low-latency reads and
updates are required. The resulting system should be linearly scalable, and it
should scale out rather than up.

1. All data entering the system is dispatched to both the batch layer and
the speed layer for processing.
2. The batch layer has two functions:
a) Managing the master dataset (an immutable, append-only set of
raw data)
b) To pre-compute the batch views.
3. The serving layer indexes the batch views so that they can be queried
in low-latency, ad-hoc way.
4. The speed layer compensates for the high latency of updates to the
serving layer and deals with recent data only.
5. Any incoming query can be answered by merging results from batch
views and real-time views.
Twitter tweets analysis using Lambda architecture, article explains
Lambda architecture as follows:

This architecture is classified into three layers:

Batch Layer: The batch layer precomputes the master dataset (it is core components of
lambda architecture and it contains all data) into batch views so that queries can be resolved
with low latency.

Speed Layer: In speed layer we are basically do two things, storing the real-time views and
processing the incoming data stream so as to update those views. It fills the delta gap that is
left by batch layer. that means combine speed layer view and batch view give us capability
fire any adhoc query over all data that is query=function(over all data).

Serving Layer: It provides low-latency access to the results of calculations performed on the
master dataset. It combines batch view and real-time view to give result in real-time for any
adhoc query over all data.

You might also like