Lessons from microservices failures - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is a common cause of cascading failures in microservices?

In a microservices architecture, what often triggers cascading failures that affect multiple services?

A Deploying services with different programming languages

B Using too many databases for different services

C A single service becoming overloaded and causing dependent services to fail

D Having too many developers working on the same service

💡 Hint

Think about how one service's failure can impact others that rely on it.

Cascading failures happen when one overloaded or failing service causes its dependent services to also fail, spreading the problem.

❓ Architecture

intermediate

Which design helps prevent cascading failures in microservices?

Which architectural pattern is best suited to isolate failures and prevent cascading effects in microservices?

A Circuit breaker pattern that stops calls to failing services

B Direct synchronous calls without retries

C Using a single database for all services

D Monolithic deployment of all services together

💡 Hint

Think about a way to stop repeated calls to a failing service.

The circuit breaker pattern detects failures and stops calls to a failing service temporarily, preventing cascading failures.

❓ scaling

advanced

What is a key challenge when scaling microservices to avoid failures?

When scaling microservices, what is a critical challenge that can lead to failures if not handled properly?

A Ensuring consistent data across distributed services

B Using the same hardware for all services

C Avoiding any form of caching

D Deploying all services in a single data center

💡 Hint

Think about data consistency when services are spread out.

Maintaining consistent data across distributed services is difficult but essential to avoid failures and data corruption.

❓ tradeoff

advanced

What is a tradeoff when using asynchronous communication in microservices?

Choosing asynchronous communication between microservices improves resilience but introduces what tradeoff?

A Higher latency in synchronous calls

B Simpler debugging and tracing

C Reduced fault tolerance

D Increased complexity in handling eventual consistency

💡 Hint

Think about data state when messages are delayed.

Asynchronous communication can cause data to be temporarily inconsistent, requiring careful handling of eventual consistency.

❓ estimation

expert

Estimate the maximum number of microservices calls per second before failure risk increases

A microservices system has 50 services, each making 10 calls per second to others. What is the approximate total number of calls per second in the system, and why does exceeding this number increase failure risk?

A 50 calls per second; exceeding this causes database locks

B 500 calls per second; exceeding this overloads network and services causing failures

C 1000 calls per second; exceeding this causes CPU overheating

D 100 calls per second; exceeding this causes memory leaks

💡 Hint

Multiply services by calls per service to find total calls.

50 services × 10 calls each = 500 calls per second. Going beyond this can overload network and services, increasing failure risk.