Bird
Raised Fist0
Microservicessystem_design~12 mins

Why microservices exist - Architecture Impact

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
System Overview - Why microservices exist

This system shows why microservices exist. It breaks a big application into smaller, independent parts. Each part does one job well. This helps teams work faster, fix problems easier, and scale parts that need more power.

Architecture Diagram
User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  +-------------------+-------------------+-------------------+-------------------+
  |                   |                   |                   |                   |
Service A          Service B           Service C           Service D
  |                   |                   |                   |
Database A         Database B          Database C          Database D
  |                   |                   |                   |
Cache A            Cache B             Cache C             Cache D
Components
User
user
Person using the application
Load Balancer
load_balancer
Distributes user requests evenly to API Gateway
API Gateway
api_gateway
Routes requests to the correct microservice
Service A
service
Handles one specific business function independently
Service B
service
Handles another specific business function independently
Service C
service
Handles a different business function independently
Service D
service
Handles yet another business function independently
Database A
database
Stores data for Service A
Database B
database
Stores data for Service B
Database C
database
Stores data for Service C
Database D
database
Stores data for Service D
Cache A
cache
Speeds up data access for Service A
Cache B
cache
Speeds up data access for Service B
Cache C
cache
Speeds up data access for Service C
Cache D
cache
Speeds up data access for Service D
Request Flow - 11 Hops
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Service A
Service A → Cache A
Cache A → Service A
Service A → Database A
Database A → Service A
Service A → Cache A
Service A → API Gateway
API Gateway → Load Balancer
Load Balancer → User
Failure Scenario
Component Fails:Database A
Impact:Service A cannot write or read fresh data; cache may serve stale data
Mitigation:Use database replication and fallback to read replicas; cache serves stale data temporarily
Architecture Quiz - 3 Questions
Test your understanding
Why does the system use multiple small services instead of one big service?
ATo reduce the number of databases
BTo allow independent development and scaling of parts
CTo make the system slower
DTo avoid using caches
Design Principle
This architecture shows how microservices break a big app into smaller parts. Each part can be built, fixed, and scaled alone. This helps teams work faster and keeps the system flexible and reliable.

Practice

(1/5)
1. Why do organizations choose microservices over a single large application?
easy
A. To write all code in one programming language
B. To make the system run only on one server
C. To avoid using any databases
D. To break a big system into smaller, manageable parts

Solution

  1. Step 1: Understand the problem with large applications

    Large applications are hard to manage, update, and scale because everything is tightly connected.

  2. Step 2: Identify microservices benefit

    Microservices split the big system into smaller parts that can be managed and updated independently.

  3. Final Answer:

    To break a big system into smaller, manageable parts -> Option D

  4. Quick Check:

    Microservices = smaller parts [OK]
Hint: Microservices split big apps into small parts [OK]
Common Mistakes:
  • Thinking microservices run only on one server
  • Believing microservices avoid databases
  • Assuming microservices require one language
2. Which of the following is a key feature of microservices architecture?
easy
A. All services share the same database schema
B. Each service can be developed and deployed independently
C. Services must be written in the same programming language
D. Microservices require a monolithic deployment

Solution

  1. Step 1: Review microservices independence

    Microservices allow teams to develop and deploy each service without affecting others.

  2. Step 2: Check other options

    Sharing the same database or language is not required; monolithic deployment contradicts microservices.

  3. Final Answer:

    Each service can be developed and deployed independently -> Option B

  4. Quick Check:

    Independent deployment = microservices [OK]
Hint: Microservices = independent deploys [OK]
Common Mistakes:
  • Assuming all services share one database
  • Believing all code must be in one language
  • Thinking microservices deploy as one unit
3. Consider a system split into microservices: User Service, Order Service, and Payment Service. If the Order Service crashes, what is the likely impact on the User Service?
medium
A. User Service continues working independently
B. User Service will lose all user data
C. User Service will also crash immediately
D. User Service will restart automatically

Solution

  1. Step 1: Understand microservices isolation

    Each microservice runs independently, so failure in one does not crash others.

  2. Step 2: Analyze impact on User Service

    User Service can keep working even if Order Service crashes, though some features may be limited.

  3. Final Answer:

    User Service continues working independently -> Option A

  4. Quick Check:

    Microservices isolation = independent operation [OK]
Hint: Microservices fail independently, not together [OK]
Common Mistakes:
  • Assuming one service crash crashes all
  • Thinking user data is lost when order fails
  • Believing services auto-restart always
4. A team built a microservices system but notices that deploying one service requires stopping the entire system. What is the likely mistake?
medium
A. Services are tightly coupled and not independent
B. They are using too many programming languages
C. The database is too large
D. They did not write enough tests

Solution

  1. Step 1: Identify deployment problem

    If deploying one service stops the whole system, services are not independent as microservices require.

  2. Step 2: Rule out other options

    Programming languages, database size, or tests do not cause deployment to stop all services.

  3. Final Answer:

    Services are tightly coupled and not independent -> Option A

  4. Quick Check:

    Independent services = independent deploys [OK]
Hint: Independent deploy means no system-wide stop [OK]
Common Mistakes:
  • Blaming programming languages for deployment issues
  • Thinking database size causes deployment stop
  • Assuming tests affect deployment independence
5. A company wants to scale their online store quickly during sales. How does microservices architecture help achieve this?
hard
A. By forcing all services to scale together as one unit
B. By allowing only the payment service to scale independently
C. By enabling each service to scale based on its own demand
D. By removing the need for any scaling

Solution

  1. Step 1: Understand scaling in microservices

    Microservices let each part of the system scale separately depending on its load.

  2. Step 2: Apply to online store scenario

    During sales, services like Order or Payment can scale more without scaling unrelated services.

  3. Final Answer:

    By enabling each service to scale based on its own demand -> Option C

  4. Quick Check:

    Microservices scale independently = efficient scaling [OK]
Hint: Scale each service separately for efficiency [OK]
Common Mistakes:
  • Thinking only one service scales
  • Believing all services must scale together
  • Assuming microservices remove scaling needs