When to revert to monolith in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Identifying the right time to revert to a monolith

Which scenario best indicates that a microservices architecture should be reverted back to a monolith?

A When the system has too many small services causing high operational overhead and complex debugging.

B When the system requires strict isolation for security and compliance reasons.

C When different teams require full independence to deploy services separately.

D When the system needs to scale out rapidly to handle millions of users.

💡 Hint

Think about when microservices add more complexity than benefits.

Too many small services can increase operational overhead and make debugging difficult, which is a common reason to revert to a monolith for simplicity.

❓ Architecture

intermediate

Choosing architecture based on team size and product maturity

A startup has a small team and a product in early development. Which architecture choice is most suitable?

A Adopt microservices immediately to prepare for future scaling.

B Build multiple monoliths for different features.

C Start with a monolith to reduce complexity and speed up development.

D Use a serverless architecture to avoid managing infrastructure.

💡 Hint

Consider simplicity and speed for small teams.

Starting with a monolith helps small teams move faster and avoid the overhead of managing many services.

❓ scaling

advanced

Scaling challenges indicating a monolith reversion

Which scaling challenge is a strong signal to consider reverting from microservices to a monolith?

A When the system requires horizontal scaling of stateless services.

B When network latency between services causes significant performance degradation.

C When individual services can be scaled independently without issues.

D When the deployment pipeline supports continuous integration for all services.

💡 Hint

Think about communication overhead between services.

High network latency between many microservices can degrade performance, suggesting a monolith might be more efficient.

❓ tradeoff

advanced

Tradeoffs in reverting to monolith from microservices

What is a major tradeoff when reverting from microservices back to a monolith?

A Simplified deployment but reduced team autonomy and slower feature releases.

B Increased operational complexity but faster debugging.

C Improved fault isolation but harder to scale individual components.

D Better security isolation but increased network overhead.

💡 Hint

Consider how deployment and team workflows change.

Reverting to a monolith simplifies deployment but reduces the ability for teams to deploy independently, potentially slowing releases.

❓ estimation

expert

Estimating operational overhead in microservices vs monolith

A system has 50 microservices, each requiring 2 hours of daily maintenance. If reverted to a monolith requiring 10 hours daily maintenance, what is the daily operational overhead saved?

A 50 hours saved daily

B 100 hours saved daily

C 40 hours saved daily

D 90 hours saved daily

💡 Hint

Calculate total hours before and after, then find the difference.

50 services * 2 hours = 100 hours before; monolith = 10 hours; saved = 100 - 10 = 90 hours.