When to revert to monolith in Microservices - Interactive Code Practice

Practice - 5 Tasks

1fill in blank

easy

Complete the code to identify a common reason to revert to a monolith.

Microservices

if system_complexity > [1]:
    consider_revert = True

Drag options to blanks, or click blank then click option'

Ahigh

Blow

Cmedium

Dzero

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing 'low' or 'zero' complexity as reasons to revert.

High system complexity often makes microservices hard to manage, so reverting to a monolith can simplify development.

2fill in blank

medium

Complete the code to check if latency issues suggest reverting to a monolith.

Microservices

if average_latency > [1]:
    revert_to_monolith = True

Drag options to blanks, or click blank then click option'

A500ms

B10ms

C1s

D100ms

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing too low or too high latency values.

Latency above 500ms can degrade user experience, indicating microservices might be causing delays.

3fill in blank

hard

Fix the error in the code that decides to revert based on deployment complexity.

Microservices

if deployment_steps > [1]:
    revert = True

Drag options to blanks, or click blank then click option'

A5

B20

C10

D50

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing too low or too high numbers that don't reflect practical deployment complexity.

More than 10 deployment steps can indicate too much overhead, suggesting a monolith might be simpler.

4fill in blank

hard

Fill both blanks to complete the condition for reverting to monolith based on team size and communication overhead.

Microservices

if team_size > [1] and communication_channels > [2]:
    revert = True

Drag options to blanks, or click blank then click option'

A15

B10

C45

D20

Attempts:

3 left

💡 Hint

Common Mistakes

Mixing up team size and communication channel numbers.

Teams larger than 15 with over 45 communication channels often face coordination issues, making monoliths preferable.

5fill in blank

hard

Fill all three blanks to complete the code deciding to revert based on data consistency, transaction complexity, and monitoring difficulty.

Microservices

if data_consistency == [1] and transaction_complexity > [2] and monitoring_difficulty == [3]:
    revert_to_monolith = True

Drag options to blanks, or click blank then click option'

Astrong

Bhigh

Chard

Deventual

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing 'eventual' consistency or low complexity values.

Strong data consistency, high transaction complexity, and hard monitoring suggest microservices may be too complex, favoring monoliths.

Practice

1. Which of the following is a common reason to revert from microservices back to a monolith?

easy

A. When you want to increase the number of services for better modularity

B. When the system needs to handle more users simultaneously

C. When you want to add more independent teams to work on the project

D. When microservices cause too much complexity and slow down development

Solution

1. Step 1: Understand microservices complexity

   Microservices can add overhead in communication and deployment, increasing complexity.

2. Step 2: Identify when to simplify

   If complexity slows development or causes performance issues, reverting to monolith helps.

3. Final Answer:

   When microservices cause too much complexity and slow down development -> Option D

4. Quick Check:

   Complexity and slow development = revert to monolith [OK]

Hint: Choose option mentioning complexity or slow development [OK]

Common Mistakes:

• Confusing scalability needs with reverting reasons
• Thinking more services always improve modularity
• Assuming more teams mean revert to monolith

2. Which syntax correctly describes a scenario to revert to monolith in a system design document?

easy

A. If (microservices_complexity > threshold) then revert_to_monolith()

B. while (services_count < max) { add_service(); }

C. deploy(microservices) if performance is good

D. scale(monolith) when load increases

Solution

1. Step 1: Analyze the condition for reverting

   The condition to revert is when microservices complexity exceeds a limit.

2. Step 2: Match syntax to scenario

   If (microservices_complexity > threshold) then revert_to_monolith() correctly uses a conditional to revert when complexity is high.

3. Final Answer:

   If (microservices_complexity > threshold) then revert_to_monolith() -> Option A

4. Quick Check:

   Condition on complexity triggers revert = If (microservices_complexity > threshold) then revert_to_monolith() [OK]

Hint: Look for condition checking complexity before revert [OK]

Common Mistakes:

• Choosing loops or unrelated deployment commands
• Ignoring the revert condition in syntax
• Confusing scaling with reverting

3. Given a microservices system with high network latency causing slow responses, what is the likely output of reverting to a monolith?

medium

A. Reduced network overhead and faster response times

B. Increased network calls and slower response times

C. More complex deployment pipelines

D. Increased service discovery failures

Solution

1. Step 1: Understand network latency impact

   Microservices communicate over network, causing latency and slow responses.

2. Step 2: Effect of reverting to monolith

   Combining services reduces network calls, lowering latency and improving speed.

3. Final Answer:

   Reduced network overhead and faster response times -> Option A

4. Quick Check:

   Less network calls = faster responses [OK]

Hint: Revert reduces network calls, so responses get faster [OK]

Common Mistakes:

• Thinking reverting increases network calls
• Confusing deployment complexity with runtime latency
• Assuming service discovery issues increase after revert

4. You have a microservices system with many small services causing deployment failures. Which fix correctly reverts to a monolith?

medium

A. Split services further to isolate failures

B. Combine services into a single deployable unit

C. Add more network retries for service calls

D. Increase the number of service instances

Solution

1. Step 1: Identify deployment failure cause

   Many small services increase deployment complexity and failure risk.

2. Step 2: Correct revert action

   Combining services into one unit simplifies deployment and reduces failures.

3. Final Answer:

   Combine services into a single deployable unit -> Option B

4. Quick Check:

   Combine services to simplify deployment [OK]

Hint: Fix deployment by combining services into one unit [OK]

Common Mistakes:

• Splitting services more instead of combining
• Adding retries doesn't fix deployment complexity
• Scaling instances doesn't solve deployment failures

5. A company has 20 microservices but faces slow feature delivery and high operational costs. What is the best approach to decide if reverting to a monolith is suitable?

hard

A. Add more microservices to distribute workload evenly

B. Immediately merge all services into one monolith to reduce costs

C. Evaluate team size, deployment complexity, and performance bottlenecks before deciding

D. Ignore operational costs and focus only on scaling microservices

Solution

1. Step 1: Analyze factors affecting delivery and costs

   Team size, deployment complexity, and performance issues impact delivery speed and costs.

2. Step 2: Make informed decision

   Evaluating these factors helps decide if reverting to monolith improves simplicity and efficiency.

3. Final Answer:

   Evaluate team size, deployment complexity, and performance bottlenecks before deciding -> Option C

4. Quick Check:

   Balanced evaluation guides revert decision [OK]

Hint: Assess team and complexity before reverting [OK]

Common Mistakes:

• Rushing to merge without analysis
• Adding more services without solving issues
• Ignoring costs and focusing only on scaling