Why microservices exist - Scalability Evidence

Scalability Analysis - Why microservices exist

Growth Table: Why Microservices Exist

Users / Scale	System Characteristics	Challenges	Why Microservices Help
100 users	Simple app, few features, single codebase	Low complexity, easy to manage	Monolith works fine, microservices overhead not justified
10,000 users	Growing features, more developers, some performance needs	Codebase grows, deployments slow, teams overlap	Microservices start to help by splitting features, enabling parallel work
1,000,000 users	High traffic, many features, multiple teams, complex deployments	Monolith too big, slow to deploy, hard to scale parts independently	Microservices enable independent scaling, faster deployments, fault isolation
100,000,000 users	Massive scale, global users, continuous delivery, many teams	Monolith impossible to manage, scaling bottlenecks, deployment risks	Microservices essential for scalability, team autonomy, resilience

First Bottleneck: Monolithic Architecture Limits

As user count and features grow, a single large codebase becomes hard to manage.

Deployments take longer because all code must be tested and released together.

Scaling the whole app wastes resources; some parts need more power than others.

Teams block each other due to shared code and dependencies.

This slows innovation and increases risk of failures affecting entire system.

Scaling Solutions Enabled by Microservices

• Horizontal scaling: Scale individual services independently based on load.
• Team autonomy: Small teams own specific services, speeding development.
• Fault isolation: Failures in one service don't crash the whole app.
• Technology diversity: Use best tools per service without affecting others.
• Continuous deployment: Deploy services independently for faster releases.
• Data isolation: Each service manages its own data, reducing conflicts.

Back-of-Envelope Cost Analysis

At 1 million users, assume 10 requests per user per day = 10 million requests/day (~115 QPS).

Monolith must handle all requests; scaling entire app is costly and inefficient.

Microservices let you scale only busy parts, saving CPU and memory.

Storage is split per service, reducing contention and improving performance.

Network overhead increases due to inter-service calls but is manageable with good design.

Interview Tip: Structuring Your Scalability Discussion

1. Start by describing the current system and its scale.
2. Identify bottlenecks as user count grows (codebase size, deployment speed, scaling limits).
3. Explain why a monolith struggles at larger scale.
4. Introduce microservices as a solution to these problems.
5. Discuss benefits: independent scaling, team autonomy, fault isolation.
6. Mention trade-offs like increased complexity and network overhead.
7. Conclude with how microservices enable sustainable growth.

Self-Check Question

Your monolithic app's database handles 1000 queries per second (QPS). Traffic grows 10x to 10,000 QPS. What do you do first and why?

Answer: The database is the first bottleneck. To handle 10x traffic, first add read replicas and caching to reduce load. Then consider splitting the monolith into microservices to scale parts independently and reduce database contention.

Key Result

Microservices exist to solve scaling and management challenges of large, complex applications by enabling independent scaling, faster deployments, and team autonomy.

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