First microservice architecture diagram in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Identify the main components in a simple microservice architecture

Look at a basic microservice architecture diagram with these components: API Gateway, User Service, Order Service, Database, and Message Queue.

Which component handles client requests first?

A User Service

B API Gateway

C Database

D Message Queue

💡 Hint

Think about which part acts as the entry point for all client requests.

The API Gateway is the first component that receives client requests and routes them to the appropriate microservice.

❓ scaling

intermediate

Scaling microservices for high traffic

You have a microservice that handles user profiles. Traffic is increasing rapidly. Which approach best supports scaling this microservice?

A Combine User Service and Order Service into one service

B Add more CPU cores to the database server

C Use a single instance with more memory

D Deploy multiple instances of the User Service behind a load balancer

💡 Hint

Think about horizontal scaling and distributing load.

Deploying multiple instances behind a load balancer allows the service to handle more requests by distributing traffic.

❓ tradeoff

advanced

Choosing between synchronous and asynchronous communication

In a microservice architecture, what is a key tradeoff when choosing asynchronous messaging over synchronous HTTP calls?

A Asynchronous messaging improves system resilience but increases complexity in data consistency

B Asynchronous messaging reduces latency but causes tight coupling between services

C Synchronous HTTP calls improve fault tolerance but reduce throughput

D Synchronous HTTP calls eliminate the need for message brokers

💡 Hint

Consider how asynchronous communication affects system design and data handling.

Asynchronous messaging allows services to continue working if others are slow or down, improving resilience, but it makes keeping data consistent harder.

🧠 Conceptual

advanced

Understanding service discovery in microservices

What is the main purpose of a service discovery component in a microservice architecture?

A To store user data securely

B To balance load between database replicas

C To allow services to find and communicate with each other dynamically

D To cache responses for faster access

💡 Hint

Think about how services know where other services are located.

Service discovery helps services locate each other’s network addresses dynamically, enabling communication without hardcoding locations.

❓ estimation

expert

Estimating capacity for a microservice handling 10,000 requests per second

You design a microservice expected to handle 10,000 requests per second. Each request takes 50ms CPU time on average. How many instances are needed to handle the load without queuing?

A At least 500 instances

B At least 200 instances

C At least 100 instances

D At least 50 instances

💡 Hint

Calculate total CPU time per second and divide by CPU time per instance.

Each request takes 0.05 seconds CPU time. 10,000 requests per second means 500 CPU-seconds needed per second. One instance (assuming 1 CPU core) can handle 1 CPU-second per second. So, 500 instances are needed to handle the load without queuing.

Practice

1. What is the main role of an API Gateway in a microservice architecture?

easy

A. It stores all the data for the microservices.

B. It routes client requests to the correct microservice.

C. It runs the user interface of the application.

D. It replaces all microservices with a single service.

Solution

1. Step 1: Understand the API Gateway function

   The API Gateway acts as a single entry point that directs client requests to the appropriate microservice.

2. Step 2: Compare other options

   Storing data is done by individual services, not the gateway. The UI runs separately, and the gateway does not replace microservices.

3. Final Answer:

   It routes client requests to the correct microservice. -> Option B

4. Quick Check:

   API Gateway = Request Router [OK]

Hint: API Gateway directs requests, it does not store data [OK]

Common Mistakes:

• Thinking API Gateway stores data
• Confusing API Gateway with UI component
• Assuming API Gateway replaces microservices

2. Which of the following correctly shows a microservice owning its own data?

easy

A. Multiple microservices share one database directly.

B. Microservices do not use databases at all.

C. Each microservice has its own separate database.

D. All microservices write to a single shared file.

Solution

1. Step 1: Recall microservice data ownership principle

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

2. Step 2: Evaluate options

   Sharing one database or file breaks independence. Not using databases is unrealistic for data needs.

3. Final Answer:

   Each microservice has its own separate database. -> Option C

4. Quick Check:

   Microservice = Own Data Store [OK]

Hint: Microservices keep data separate, no shared DB [OK]

Common Mistakes:

• Assuming all services share one database
• Thinking microservices don't need databases
• Using shared files for data storage

3. Given this simple microservice setup:
Client -> API Gateway -> Service A -> Service B
What happens if Service B is down when Client sends a request?

medium

A. The API Gateway automatically retries Service B until it responds.

B. The API Gateway routes the request to Service B's backup automatically.

C. The client request is handled fully by Service A without contacting Service B.

D. Service A will fail to complete the request and return an error to the client.

Solution

1. Step 1: Trace request flow with Service B down

   The client request goes through API Gateway to Service A, which calls Service B. If Service B is down, Service A cannot complete its task.

2. Step 2: Understand failure impact

   Without Service B responding, Service A returns an error back through the API Gateway to the client.

3. Final Answer:

   Service A will fail to complete the request and return an error to the client. -> Option D

4. Quick Check:

   Down service causes error response [OK]

Hint: Down service causes error, no automatic retry [OK]

Common Mistakes:

• Assuming automatic retries by API Gateway
• Thinking Service A can handle request alone
• Believing API Gateway has backup routing

4. In this microservice diagram, the API Gateway calls Service A and Service B directly. But Service A calls Service B internally and Service B calls Service A internally.
What is the main problem with this design?

medium

A. It creates a circular dependency between services.

B. API Gateway should not call any services directly.

C. Services should share one database instead.

D. Service A should call Service B, not the other way.

Solution

1. Step 1: Identify service call relationships

   API Gateway calls both Service A and Service B, and Service A calls Service B and Service B calls Service A, forming a loop.

2. Step 2: Understand circular dependency issues

   Circular dependencies cause tight coupling and can lead to failures or deadlocks.

3. Final Answer:

   It creates a circular dependency between services. -> Option A

4. Quick Check:

   Circular calls = Bad design [OK]

Hint: Avoid circular calls between microservices [OK]

Common Mistakes:

• Thinking API Gateway shouldn't call services
• Believing shared database fixes call loops
• Assuming call direction must be reversed

5. You want to design a microservice architecture for an online store with these needs:
- User service manages user profiles
- Product service manages product info
- Order service creates orders and needs user and product data

Which architecture diagram best fits these requirements?

hard

A. Client -> API Gateway -> User Service, Product Service, Order Service; Order Service calls User and Product Services internally.

B. Client -> API Gateway -> Order Service only; Order Service manages users and products internally.

C. Client -> API Gateway -> User Service and Product Service only; Order Service is part of API Gateway.

D. Client -> API Gateway -> User Service; Product Service calls Order Service; Order Service calls User Service.

Solution

1. Step 1: Analyze service responsibilities

   User and Product services manage their own data. Order service needs to create orders using data from both.

2. Step 2: Check communication flow

   Order service calling User and Product services internally keeps responsibilities clear and allows data ownership.

3. Step 3: Evaluate options

   Client -> API Gateway -> User Service, Product Service, Order Service; Order Service calls User and Product Services internally. matches this design. Others either merge services incorrectly or create wrong call flows.

4. Final Answer:

   Client -> API Gateway -> User Service, Product Service, Order Service; Order Service calls User and Product Services internally. -> Option A

5. Quick Check:

   Order service calls needed services [OK]

Hint: Order service calls user and product services internally [OK]

Common Mistakes:

• Merging all logic into one service
• Placing order service inside API Gateway
• Incorrect service call directions