Scribd
Upload
57 views3 pages

Micro Services

The document discusses several challenges and advantages of microservices architecture as well as common patterns used in microservices. Some key challenges include inter-service communication, distributed logging, and transaction spanning across services. Advantages include evolutionary design, small codebases, and ability to auto scale individual services. Common patterns discussed are the SAGA pattern for distributed transactions, circuit breaker pattern to handle failures, and API gateways for routing requests.

Uploaded by

Disha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
57 views3 pages

Micro Services

The document discusses several challenges and advantages of microservices architecture as well as common patterns used in microservices. Some key challenges include inter-service communication, distributed logging, and transaction spanning across services. Advantages include evolutionary design, small codebases, and ability to auto scale individual services. Common patterns discussed are the SAGA pattern for distributed transactions, circuit breaker pattern to handle failures, and API gateways for routing requests.

Uploaded by

Disha
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

1.

Challenges of MicroService
The MicroService architecture helps a lot, but comes with its own challenges.
• Inter Service Communication – MicroServices will rely on each other and they will have to
communicate. A common communication channel needs to be framed using HTTP/ESB etc.
• Health Monitoring – There are more services to monitor which may be developed using
different programming languages.
• Distributed logging – Different services will have its own logging mechanism, resulting GBs of
distributed unstructured data.
• Transaction Spanning – MicroServices may result in spanning of transactions over multiple
services & database. An issues caused somewhere will result is some other issues somewhere
else.
• Finding root cause – Distributed logic with distributed data increases the effort of finding the
root cause. The performance related root cause can still be managed using APM tools like New
Relic & Dynatrace.
• Cyclic dependencies between services – Reproducing a problem will prove to be very difficult
when it’s gone in one version, and comes back with a newer one.

2. Advantages of MicroServices
• Evolutionary Design – No need to rewrite your whole application. Add new features as
MicroServices, and plug them into your existing application
• Small Codebase – Each MicroService deals with one concern(SoC) only – this result in a small
codebase, which means easier maintainability
• Auto Scale – freedom to scale only the loaded service, as that service will handle the bigger
load.
• Easy to Deploy – Deploy only the needed codebase, instead of redeploying the entire
application.
• System Resilience – If some of the services go down only some features will be affected, not
the entire application.

● SAGA Pattern in Microservices


The Saga design pattern is a way to manage data consistency across microservices in
distributed transaction scenarios. A saga is a sequence of transactions that updates each
service and publishes a message or event to trigger the next transaction step.
This is the SAGA Orchestrator pattern where we have a central Saga Execution Coordinator

Each service implements a Compensation endpoint for a transaction and the coordinator calls it.
Other option is a choreography pattern where services themselves undo the previous
transactions

3. What is the circuit breaker pattern in microservices


We can use circuit breaker pattern where a proxy service acts as a circuit breaker. Each service
should be invoked through proxy service. A proxy service maintains a timeout and failures
count. In case of consecutive failures crosses the threshold failures count then proxy service
trips the circuit breaker and starts a timeout period. During this timeout period, all requests will
failed. Once this timeout period is over, proxy service allows a given limited number of test
requests to pass to provider service. If requests succeed the proxy service resumes the
operations otherwise, it agains trips the circuit breaker and starts a timeout period and no
requests will be entertained during that period.

4. What is API Gateway?


5. What is service discovery and service registry? Why do you need to register?
6. If you have API Gateway do you need service discovery
7. How to identify if a MS goes down?
8. What is circuit breaker pattern
9. What is saga pattern?
● What is the 12 factor methodology in microservices? (NOT VERY IMP)
The twelve-factor methodology is a set of twelve best practices to develop applications
developed to run as a service. This was originally drafted by Heroku for applications deployed
as services on their cloud platform, back in 2011
1. CODEBASE - an app should be tracked in a single code repository and must not share
that repository with any other apps
2. Dependencies - the twelve-factor app should always explicitly declare all its
dependencies. ( dependencies usually have other transitive dependencies but we need
to explicitly declare the ones we need.)
3. COnfiguration - A twelve-factor app should externalize all such configurations that vary
between deployments.
4. Backing Services - A twelve-factor app should treat all such backing services as
attached resources. What this effectively means is that it shouldn't require any code
change to swap a compatible backing service. The only change should be in
configurations. (SHould be able to move between DBs just with config change)
5. Build, Release, Run - The twelve-factor methodology strictly separates the process of
converting codebase into a running application as three distinct stages: Build , Release
and Run
6. Statelessness - A twelve-factor app is expected to run in an execution environment as
stateless processes.
7. Port Binding - The twelve-factor app is completely self-contained and does not rely on
runtime injection of a webserver into the execution environment to create a web-facing
service. (SpringBoot supports, not spring since we need a tomcat server)
8. Concurrency - The twelve-factor methodology suggests apps to rely on processes for
scaling. What this effectively means is that applications should be designed to distribute
workload across multiple processes.(Use docker and k8s for this)
9. Disposability - Application processes can be shut down on purpose or through an
unexpected event. In either case, a twelve-factor app is supposed to handle it gracefully.
10. Dev/Prod parity - The twelve-factor methodology suggests keeping the gap
between development and production environment as minimal as possible. These gaps
can result from long development cycles, different teams involved, or different
technology stack in use.
11. Logs - A twelve-factor app, however, separates itself from log generation and its
processing.
12. Admin Processes - the twelve-factor methodology strongly suggests keeping
such admin scripts together with the application codebase(Like a 1 time insert script)

You might also like