When to use microservices (and when not to) - Scalability & System Analysis

Scalability Analysis - When to use microservices (and when not to)

Growth Table: Microservices Adoption at Different Scales

Users	System Complexity	Team Size	Deployment Frequency	Service Boundaries
100 users	Simple, monolith works well	Small (1-5)	Low to medium	Not needed
10,000 users	Growing complexity, some modularity	Medium (5-20)	Medium	Consider splitting key modules
1,000,000 users	High complexity, many features	Large (20+)	High, frequent releases	Microservices beneficial
100,000,000 users	Very high complexity, global scale	Very large, multiple orgs	Continuous delivery	Microservices essential for scale

First Bottleneck: When Microservices Are Needed

At small scale, the main bottleneck is development speed and coordination. A monolith is easier to manage.

As users and features grow, the codebase becomes large and hard to maintain. Teams slow down due to dependencies.

The first bottleneck is the development and deployment velocity caused by tightly coupled code and shared databases.

Microservices help by splitting the system into smaller, independent parts owned by small teams.

Scaling Solutions: When to Use Microservices

• Use microservices when:
  • System complexity is high with many features.
  • Multiple teams need to work independently.
  • Frequent, independent deployments are required.
  • Different parts of the system have different scaling needs.
  • Technology diversity is beneficial (different languages/databases per service).
• Do NOT use microservices when:
  • System is small or simple.
  • Team size is small and communication is easy.
  • Operational overhead of microservices is too high.
  • Latency between services would hurt user experience.
  • Strong consistency and transactions across services are critical and complex.

Back-of-Envelope Cost Analysis

At 1,000 users, a single server and database handle ~100-500 requests per second easily.

At 10,000 users, requests grow to ~1,000-5,000 QPS; a monolith with caching can still work.

At 1,000,000 users, requests can reach ~100,000 QPS; a single database struggles with this load.

Microservices allow splitting load across multiple databases and servers, reducing bottlenecks.

Operational costs increase due to multiple deployments, monitoring, and network overhead.

Interview Tip: Structuring Your Scalability Discussion

Start by describing the current system scale and team size.

Explain the pain points: slow deployments, tight coupling, scaling issues.

Identify the first bottleneck: development velocity or database load.

Propose microservices only if complexity and team size justify it.

Discuss trade-offs: operational overhead vs. independent scaling.

Self-Check Question

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and caching to reduce database load before splitting into microservices.

Key Result

Microservices are best used when system complexity and team size grow large enough that a monolith slows development and scaling; otherwise, they add unnecessary overhead.