Anti-patterns (distributed monolith, chatty services) in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identifying a Distributed Monolith

Which of the following best describes a distributed monolith in a microservices architecture?

A A system where each microservice is fully independent and communicates only via asynchronous events.

B A system where services are tightly coupled and require synchronous calls, causing deployment and scaling challenges.

C A monolithic application running on a single server without any service boundaries.

D A system where microservices use a shared database but have independent deployment cycles.

💡 Hint

Think about coupling and communication patterns that make microservices behave like a single unit.

A distributed monolith occurs when microservices are tightly coupled, often requiring synchronous communication and shared databases, making them hard to deploy or scale independently.

❓ Architecture

intermediate

Reducing Chatty Service Calls

You have a microservices system where Service A calls Service B, which then calls Service C, causing high latency due to many synchronous calls. Which architectural change best reduces this chatty service problem?

A Combine Services B and C into a single service to reduce inter-service calls.

B Add more synchronous calls between Service A and Service C to balance the load.

C Use a shared database for all services to avoid service-to-service communication.

D Increase the timeout values for all service calls to handle latency better.

💡 Hint

Think about reducing the number of calls by merging tightly coupled services.

Merging Services B and C reduces the number of synchronous calls, thus lowering latency and avoiding chatty communication.

❓ scaling

advanced

Scaling Challenges in Distributed Monoliths

In a distributed monolith, what is the main challenge when trying to scale individual microservices independently?

A Services share a database schema, so scaling one service requires scaling the entire database, limiting independent scaling.

B Services communicate only via asynchronous messaging, which simplifies scaling.

C Each service has its own database, so scaling one service does not affect others.

D Microservices are stateless, so scaling is automatic and independent.

💡 Hint

Consider how shared resources affect scaling.

When services share a database schema, scaling one service often requires scaling the shared database, limiting independent scaling and causing bottlenecks.

❓ tradeoff

advanced

Tradeoffs of Reducing Chatty Services

What is a common tradeoff when reducing chatty service calls by merging multiple microservices into one?

A Simpler database schema but more complex inter-service communication.

B Increased network latency but better fault isolation.

C Improved performance but reduced service autonomy and harder independent deployment.

D Better scalability but increased risk of data inconsistency.

💡 Hint

Think about what merging services affects besides communication.

Merging services reduces communication overhead but decreases autonomy, making independent deployment and scaling more difficult.

❓ estimation

expert

Estimating Impact of Chatty Services on Latency

Consider a microservices system where each synchronous call adds 50ms latency. Service A calls Service B, which calls Service C, which calls Service D sequentially. What is the total added latency due to these calls?

A 200ms

B 50ms

C 100ms

D 150ms

💡 Hint

Count the number of calls and multiply by latency per call.

There are 3 synchronous calls (A->B, B->C, C->D). Each call adds 50ms, so total added latency is 3 * 50ms = 150ms.