Why microservices exist - Why This Architecture

Problem Statement

When a single application grows too large, it becomes hard to understand, change, and deploy. Teams get blocked waiting on each other, and a small bug can crash the entire system, causing long outages.

Solution

Microservices break the application into small, independent services that each handle a specific function. Each team owns one or more services, so they can develop, test, and deploy independently without affecting others.

Architecture

Service A

→Service B

↓

Team A

This diagram shows independent services owned by separate teams communicating with each other, illustrating the separation and autonomy of microservices.

Trade-offs

✓ Pros

→

Teams can develop and deploy services independently, speeding up delivery.

→

Failures in one service do not crash the entire system, improving reliability.

→

Services can be scaled individually based on demand, optimizing resource use.

→

Technology choices can vary per service, allowing best fit for each function.

✗ Cons

→

Increased complexity in managing many services and their communication.

→

Requires robust monitoring and logging to trace issues across services.

→

Data consistency is harder to maintain across distributed services.

When the application is large with multiple teams working in parallel, or when independent scaling and deployment are critical, typically beyond tens of developers or services.

For small applications or teams under 10 developers where the overhead of managing many services outweighs benefits.

Real World Examples

Netflix

Solved the problem of scaling video streaming by splitting into microservices like user management, recommendations, and playback, allowing independent scaling and deployment.

Amazon

Moved from a monolith to microservices to enable independent teams to own services like orders, payments, and inventory, speeding up feature delivery.

Uber

Used microservices to separate ride matching, payments, and notifications, improving system reliability and allowing rapid feature development.

Alternatives

Monolithic Architecture

All functionality is built and deployed as a single unit without service boundaries.

Use when: When the application is small, simple, or early in development with a small team.

Modular Monolith

Application is a single deployable unit but internally divided into modules with clear boundaries.

Use when: When you want some separation of concerns without the complexity of distributed systems.

Summary

Large applications become hard to manage and deploy as a single unit, causing delays and outages.

Microservices split the app into independent services owned by separate teams, enabling faster development and better reliability.

This approach suits large teams and complex systems but adds operational complexity and requires careful management.

Practice

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