Microservices characteristics - Scalability & System Analysis

Scalability Analysis - Microservices characteristics

Growth Table: Microservices Characteristics Scaling

Users / Traffic	Service Count	Deployment Complexity	Data Management	Communication	Monitoring & Logging
100 users	Few (5-10)	Simple, manual deploys	Single DB or shared DB	Simple REST calls	Basic logs, manual checks
10,000 users	Moderate (20-50)	Automated CI/CD pipelines	Database per service starts	REST + message queues	Centralized logging, alerts
1,000,000 users	Many (100+)	Fully automated, container orchestration	Polyglot persistence, sharding	Asynchronous messaging, event-driven	Distributed tracing, metrics dashboards
100,000,000 users	Hundreds to thousands	Multi-cluster, multi-region deployments	Data partitioning, CQRS, event sourcing	High-throughput event buses, service mesh	AI-driven monitoring, anomaly detection

First Bottleneck

At small scale, the first bottleneck is often service communication latency because many microservices call each other synchronously, causing delays.

As users grow, database scaling becomes the bottleneck since each service may have its own database increasing load and complexity.

At large scale, deployment and operational complexity breaks first due to managing many services, versions, and dependencies.

Scaling Solutions

• Horizontal scaling: Add more instances of services behind load balancers.
• Service decomposition: Split large services into smaller focused ones.
• Asynchronous communication: Use message queues and event buses to reduce latency.
• Database per service: Isolate data to reduce contention and enable independent scaling.
• Container orchestration: Use Kubernetes or similar to automate deployment and scaling.
• Service mesh: Manage service-to-service communication, retries, and security.
• Centralized monitoring: Implement distributed tracing and metrics aggregation.

Back-of-Envelope Cost Analysis

Assuming 1 million users generating 10 requests per second each, total requests = 10 million RPS.

Each service instance handles ~2000 RPS, so need ~5000 instances distributed across services.

Database load is split; each DB handles ~5000 RPS, so need many DB shards or replicas.

Network bandwidth must support inter-service calls; estimate 1 Gbps per 1000 instances.

Storage grows with data per service; consider tiered storage and archiving.

Interview Tip

Start by explaining microservices basics: independent deployability, decentralized data, and communication patterns.

Discuss scaling challenges at different user levels and identify the first bottleneck clearly.

Propose targeted solutions like asynchronous messaging and container orchestration.

Use real numbers to justify your scaling approach and show awareness of operational complexity.

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 implement caching to reduce direct DB load before considering sharding or redesign.

Key Result

Microservices scale by decomposing functionality into independent services, but first bottlenecks appear in communication latency and database load. Solutions include asynchronous messaging, database per service, and container orchestration to manage complexity.

Practice

1. Which of the following is a key characteristic of microservices architecture?

easy

A. Services must be written in the same programming language

B. All services share a single database schema

C. Each service is independently deployable and scalable

D. Microservices require a monolithic deployment

Solution

1. Step 1: Understand microservices independence

   Microservices are designed to be independent units that can be deployed and scaled separately.

2. Step 2: Evaluate options against microservices principles

   Sharing a single database or requiring the same language contradicts microservices flexibility. Monolithic deployment is opposite to microservices.

3. Final Answer:

   Each service is independently deployable and scalable -> Option C

4. Quick Check:

   Independent deployability = C [OK]

Hint: Microservices = independent small services [OK]

Common Mistakes:

• Thinking all services share one database
• Assuming same language is mandatory
• Confusing microservices with monolith

2. Which syntax correctly describes a microservice's responsibility?

easy

A. A microservice focuses on a single business capability

B. A microservice handles multiple unrelated business functions

C. A microservice must handle all user interface logic

D. A microservice should not communicate with other services

Solution

1. Step 1: Identify microservice scope

   Microservices are designed to focus on a single business capability or function.

2. Step 2: Check options for correctness

   Handling multiple unrelated functions or all UI logic is against microservices principles. Communication between services is common and necessary.

3. Final Answer:

   A microservice focuses on a single business capability -> Option A

4. Quick Check:

   Single responsibility = A [OK]

Hint: Microservice = one focused job [OK]

Common Mistakes:

• Thinking microservices do many unrelated tasks
• Believing microservices handle all UI logic
• Ignoring inter-service communication

3. Consider a microservices system where Service A calls Service B, which calls Service C. If Service B fails, what is the expected behavior in a well-designed microservices architecture?

medium

A. Service A receives an error or fallback response quickly

B. All services restart automatically

C. Service C retries the request automatically

D. Service A waits indefinitely for Service B

Solution

1. Step 1: Understand failure handling in microservices

   Microservices use timeouts and fallbacks to avoid waiting indefinitely when a service fails.

2. Step 2: Analyze options for expected behavior

   Waiting indefinitely is bad design. Service C retrying is unrelated to Service B failure. Automatic restart is not immediate failure handling.

3. Final Answer:

   Service A receives an error or fallback response quickly -> Option A

4. Quick Check:

   Timeouts and fallbacks = D [OK]

Hint: Microservices use timeouts, not infinite waits [OK]

Common Mistakes:

• Assuming infinite wait on failure
• Confusing retry logic location
• Expecting automatic restart as immediate fix

4. A developer notices that two microservices share the same database schema directly. What is the main issue with this design?

medium

A. It improves service independence

B. It creates tight coupling between services

C. It reduces data consistency

D. It simplifies service deployment

Solution

1. Step 1: Understand database ownership in microservices

   Each microservice should own its own database to avoid tight coupling.

2. Step 2: Evaluate the impact of shared schema

   Sharing schema creates tight coupling, reducing independence and flexibility. It does not improve independence or simplify deployment.

3. Final Answer:

   It creates tight coupling between services -> Option B

4. Quick Check:

   Shared DB = tight coupling = A [OK]

Hint: Microservices own separate databases [OK]

Common Mistakes:

• Thinking shared DB improves independence
• Assuming shared DB reduces consistency
• Believing shared DB simplifies deployment

5. You are designing a microservices system for an online store. Which approach best supports independent scaling and deployment of the payment and product catalog services?

hard

A. Combine payment and catalog into one service with shared database

B. Deploy payment and catalog as separate modules in the same service

C. Use a single monolithic app for both payment and catalog

D. Separate payment and catalog into distinct services with own databases and APIs

Solution

1. Step 1: Identify microservices best practices for scaling

   Independent services with own databases and APIs allow separate scaling and deployment.

2. Step 2: Compare options for independence and scalability

   Combining services or modules reduces independence. Monolith prevents separate scaling.

3. Final Answer:

   Separate payment and catalog into distinct services with own databases and APIs -> Option D

4. Quick Check:

   Separate services + DBs = B [OK]

Hint: Separate services with own DBs for scaling [OK]

Common Mistakes:

• Combining unrelated services
• Using monolith for microservices goals
• Deploying modules inside one service