Microservices characteristics - System Design Guide

Problem Statement

Monolithic applications become hard to maintain and scale as they grow. Changes in one part can affect the entire system, causing slow deployments and frequent outages.

Solution

Microservices break down a large application into small, independent services. Each service handles a specific business function and can be developed, deployed, and scaled independently.

Architecture

Service A

→Service B

↓

Database A

This diagram shows independent microservices communicating with each other and each having its own database, illustrating service isolation and autonomy.

Trade-offs

✓ Pros

→

Each service can be developed and deployed independently, speeding up releases.

→

Failures in one service do not directly affect others, improving system resilience.

→

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

→

Teams can own specific services, improving focus and expertise.

✗ Cons

→

Increased complexity in managing multiple services and their communication.

→

Requires robust monitoring and logging to trace issues across services.

→

Data consistency is harder to maintain due to distributed databases.

When the application is large and complex, requiring frequent updates and independent scaling of components. Typically beneficial when teams are large and can own separate services.

For small applications with simple functionality and low traffic, where the overhead of managing multiple services outweighs benefits.

Real World Examples

Netflix

Solved the problem of scaling video streaming by splitting functionality into microservices like user management, recommendations, and playback control.

Amazon

Used microservices to allow independent teams to develop and deploy services like product catalog, order processing, and payment handling.

Uber

Handled complex ride matching, payments, and notifications by breaking the system into microservices for better scalability and fault isolation.

Alternatives

Monolithic Architecture

All functionality is built into a single deployable unit without service boundaries.

Use when: When the application is small, simple, and requires minimal scaling or independent deployments.

Modular Monolith

Application is divided into modules within a single process, without separate deployment units.

Use when: When you want clear code separation but want to avoid the operational complexity of microservices.

Summary

Microservices split applications into small, independent services focused on specific business functions.

They enable independent development, deployment, and scaling, improving agility and resilience.

However, they introduce complexity in communication, data management, and operations.

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