Bird
Raised Fist0
Microservicessystem_design~10 mins

When to use microservices (and when not to) - Interactive Code Practice

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Practice - 5 Tasks
Answer the questions below
1fill in blank
easy

Complete the code to identify a key benefit of microservices.

Microservices
Microservices help improve [1] by breaking a system into smaller parts.
Drag options to blanks, or click blank then click option'
Ascalability
Bcomplexity
Ccost
Dlatency
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing 'complexity' because microservices can increase it.
Choosing 'cost' as microservices may increase cost initially.
2fill in blank
medium

Complete the code to state when microservices might NOT be a good choice.

Microservices
Microservices are less suitable for [1] systems with simple requirements.
Drag options to blanks, or click blank then click option'
Alarge
Bcomplex
Cdistributed
Dsmall
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing 'large' because large systems benefit from microservices.
Choosing 'complex' because complexity often calls for microservices.
3fill in blank
hard

Fix the error in the statement about microservices challenges.

Microservices
Microservices can increase [1] due to multiple services communicating over the network.
Drag options to blanks, or click blank then click option'
Acost
Bperformance
Ccomplexity
Dsecurity
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing 'performance' because microservices can sometimes improve it.
Choosing 'security' which is a concern but not the main challenge here.
4fill in blank
hard

Fill both blanks to complete the microservices trade-off statement.

Microservices
Microservices improve [1] but require more [2] to manage.
Drag options to blanks, or click blank then click option'
Ascalability
Bcost
Ccomplexity
Dperformance
Attempts:
3 left
💡 Hint
Common Mistakes
Swapping the blanks or choosing unrelated terms like 'cost' or 'performance'.
5fill in blank
hard

Fill all three blanks to complete the microservices suitability checklist.

Microservices
Use microservices when the system is [1], requires [2] deployment, and has [3] teams.
Drag options to blanks, or click blank then click option'
Alarge
Bindependent
Cmultiple
Dsimple
Attempts:
3 left
💡 Hint
Common Mistakes
Choosing 'simple' which is not suitable for microservices.
Mixing up deployment and team terms.

Practice

(1/5)
1. Which scenario is best suited for using microservices architecture?
easy
A. A large, complex application requiring independent scaling of components
B. A simple, single-function app with a small user base
C. A small script running on a single machine
D. A static website with no backend logic

Solution

  1. Step 1: Understand microservices purpose

    Microservices are designed for complex apps where parts can scale or update independently.
  2. Step 2: Match scenario to microservices benefits

    A large app needing flexibility and scaling fits microservices well; small or simple apps do not.
  3. Final Answer:

    A large, complex application requiring independent scaling of components -> Option A
  4. Quick Check:

    Complex app = microservices [OK]
Hint: Use microservices only for complex, scalable apps [OK]
Common Mistakes:
  • Choosing microservices for small or simple apps
  • Ignoring team size and management overhead
  • Assuming microservices always improve performance
2. Which of the following is a correct reason NOT to use microservices?
easy
A. The app requires frequent updates to parts
B. The application is very small and simple
C. The app needs to scale independently
D. The app has multiple teams working on different features

Solution

  1. Step 1: Identify when microservices are unnecessary

    Microservices add complexity and overhead, so small simple apps don't benefit.
  2. Step 2: Evaluate options

    Options A, B, and D are reasons to use microservices, not avoid them.
  3. Final Answer:

    The application is very small and simple -> Option B
  4. Quick Check:

    Small app = avoid microservices [OK]
Hint: Avoid microservices for small, simple apps [OK]
Common Mistakes:
  • Confusing scaling needs as a reason to avoid microservices
  • Ignoring complexity added by microservices
  • Assuming microservices fit all team sizes
3. Consider a microservices app with 5 services. If each service requires 2 developers and the team has only 6 developers total, what is the likely outcome?
medium
A. The team can easily manage all services independently
B. The services will merge into a monolith automatically
C. The team will struggle due to insufficient resources for each service
D. The app will automatically scale without developer input

Solution

  1. Step 1: Calculate developer needs

    5 services x 2 developers each = 10 developers needed.
  2. Step 2: Compare with available team size

    Only 6 developers are available, which is less than 10, causing resource strain.
  3. Final Answer:

    The team will struggle due to insufficient resources for each service -> Option C
  4. Quick Check:

    Dev shortage = struggle managing microservices [OK]
Hint: Check if team size matches microservices needs [OK]
Common Mistakes:
  • Assuming microservices scale developer needs automatically
  • Ignoring team size constraints
  • Thinking services merge automatically without effort
4. A team tries to convert a small monolithic app into microservices but faces deployment failures and communication errors. What is the most likely cause?
medium
A. Microservices do not support deployment automation
B. The app was too large for microservices
C. They used too many developers
D. They underestimated the complexity of managing microservices

Solution

  1. Step 1: Analyze the problem context

    Small apps converted to microservices often face complexity in communication and deployment.
  2. Step 2: Identify the cause

    Deployment failures and communication errors usually come from underestimating microservices management overhead.
  3. Final Answer:

    They underestimated the complexity of managing microservices -> Option D
  4. Quick Check:

    Underestimating complexity = deployment issues [OK]
Hint: Expect extra management work with microservices [OK]
Common Mistakes:
  • Blaming microservices for deployment automation lack
  • Assuming more developers cause deployment errors
  • Thinking large apps cause these specific errors
5. A startup with a small team plans to build a new app. They want to decide between microservices and a monolithic design. Which approach should they choose and why?
hard
A. Start with a monolith to reduce complexity and switch later if needed
B. Start with microservices to prepare for future scaling immediately
C. Use microservices only if the app is a static website
D. Avoid both and build multiple separate apps

Solution

  1. Step 1: Consider team size and app complexity

    A small team benefits from simpler monolithic design to reduce overhead and speed development.
  2. Step 2: Plan for future growth

    Starting monolithic allows easier initial development; microservices can be adopted later if scaling is needed.
  3. Final Answer:

    Start with a monolith to reduce complexity and switch later if needed -> Option A
  4. Quick Check:

    Small team = start monolith [OK]
Hint: Small teams start monolith, scale to microservices later [OK]
Common Mistakes:
  • Choosing microservices too early for small teams
  • Confusing static websites with microservices use
  • Ignoring future scalability planning