Microservices characteristics - Cheat Sheet & Quick Revision

Recall & Review

beginner

What does it mean for a microservice to be 'independently deployable'?

It means each microservice can be updated, tested, and deployed on its own without needing to redeploy the entire system. This allows faster and safer changes.

beginner

Why is 'single responsibility' important in microservices?

Each microservice should focus on one specific business function or capability. This keeps services simple, easier to maintain, and reduces dependencies.

intermediate

How do microservices communicate with each other?

Microservices usually communicate over lightweight protocols like HTTP/REST or messaging queues. This keeps them loosely coupled and flexible.

intermediate

What is meant by 'decentralized data management' in microservices?

Each microservice manages its own database or data storage. This avoids tight coupling and allows services to choose the best data technology for their needs.

intermediate

Explain 'fault isolation' in microservices.

Fault isolation means if one microservice fails, it does not bring down the whole system. Other services continue working, improving overall system reliability.

Which characteristic allows microservices to be updated without affecting others?

A Independent deployability

B Monolithic design

C Shared database

D Tight coupling

Independent deployability means each microservice can be deployed separately without impacting others.

What is a common way microservices communicate?

A Direct database access

B HTTP/REST or messaging

C Shared memory

D File system polling

Microservices typically use HTTP/REST or messaging queues for communication to stay loosely coupled.

Why do microservices have decentralized data management?

A To allow each service to manage its own data

B To avoid data duplication

C To share one big database

D To simplify transactions

Decentralized data management lets each microservice control its own database, reducing coupling.

What does 'single responsibility' mean for microservices?

A One service handles all functions

B Services have no responsibilities

C Services share responsibilities

D Each service handles one business function

Single responsibility means each microservice focuses on one specific business capability.

What is the benefit of fault isolation in microservices?

A All services fail together

B Faster failure propagation

C Failures in one service don't affect others

D No need for monitoring

Fault isolation ensures one service failure does not bring down the entire system.

Describe the key characteristics that make microservices scalable and maintainable.

Think about how microservices handle updates, data, and failures.

Explain how communication between microservices is designed to keep the system flexible.

Consider how services avoid tight connections.

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