Chaos engineering basics in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the primary goal of chaos engineering?

Chaos engineering is a practice used in microservices to improve system reliability. What is its main goal?

A To intentionally introduce failures to identify weaknesses before they cause real problems

B To speed up the deployment process by automating tests

C To replace manual monitoring with automated alerts

D To reduce the number of microservices in a system

💡 Hint

Think about why we would want to cause failures on purpose in a system.

Chaos engineering intentionally causes failures to find weaknesses early, so teams can fix them before users are affected.

❓ Architecture

intermediate

Which component is essential in a chaos engineering system for safely running experiments?

In a microservices architecture, chaos experiments must be controlled to avoid major outages. Which component helps manage this safely?

A Load balancer that distributes traffic evenly

B Chaos experiment orchestrator that schedules and controls failure injections

C Database replication system for backups

D API gateway for routing requests

💡 Hint

Consider which part controls when and how failures happen during chaos testing.

The chaos experiment orchestrator schedules and controls failure injections, ensuring experiments run safely and can be stopped if needed.

❓ scaling

advanced

How should chaos experiments scale in a large microservices system?

When applying chaos engineering to a large system with many microservices, what is the best approach to scaling experiments?

A Start with small, isolated experiments on critical services and gradually increase scope

B Run chaos experiments on all services simultaneously to find all issues quickly

C Scale experiments by increasing the number of injected failures per service immediately

D Only test non-critical services to avoid impacting users

💡 Hint

Think about minimizing risk while learning about system weaknesses.

Starting small and isolated reduces risk and helps understand system behavior before expanding experiments.

❓ tradeoff

advanced

What is a key tradeoff when running chaos experiments in production?

Running chaos experiments in a live production environment can improve reliability but also has risks. What is a key tradeoff?

A Choosing between faster deployments and slower rollback times

B Selecting between cloud and on-premise infrastructure

C Balancing between discovering hidden failures and risking temporary user impact

D Deciding whether to use manual or automated monitoring tools

💡 Hint

Consider what happens when you cause failures in a system users rely on.

Chaos experiments can reveal hidden issues but may cause temporary disruptions, so teams must balance learning with user experience.

❓ estimation

expert

Estimate the minimum number of chaos experiments needed to cover 10 microservices with 3 failure types each, assuming independent tests.

You have 10 microservices and want to test 3 failure types (e.g., latency, error, crash) on each independently. What is the minimum number of chaos experiments to cover all cases?

A 10 experiments

B 13 experiments

C 3 experiments

D 30 experiments

💡 Hint

Multiply the number of services by the number of failure types for independent tests.

Each microservice needs 3 separate failure tests, so 10 services × 3 failure types = 30 experiments.

Practice

1. What is the main goal of chaos engineering in microservices?

easy

A. To reduce the number of developers needed

B. To increase the number of microservices in a system

C. To find and fix weaknesses before real failures occur

D. To speed up the deployment process

Solution

1. Step 1: Understand chaos engineering purpose

   Chaos engineering is about testing systems by intentionally causing failures to find weaknesses.

2. Step 2: Identify the main goal

   The goal is to find and fix weaknesses before they cause real problems in production.

3. Final Answer:

   To find and fix weaknesses before real failures occur -> Option C

4. Quick Check:

   Chaos engineering goal = Find and fix weaknesses [OK]

Hint: Chaos engineering tests failures to improve system stability [OK]

Common Mistakes:

• Thinking chaos engineering increases microservices count
• Confusing chaos engineering with deployment speedup
• Assuming chaos engineering reduces developer count

2. Which of the following is a correct way to start chaos engineering experiments?

easy

A. Start with complex multi-service failures immediately

B. Begin with simple, controlled failure tests

C. Run chaos tests only after a system crash

D. Avoid monitoring during chaos experiments

Solution

1. Step 1: Review best practice for chaos experiments

   Best practice is to start small with simple, controlled failures to understand system behavior.

2. Step 2: Identify the correct starting approach

   Starting with simple tests helps safely learn and improve system resilience gradually.

3. Final Answer:

   Begin with simple, controlled failure tests -> Option B

4. Quick Check:

   Start chaos with simple tests = Begin with simple, controlled failure tests [OK]

Hint: Start chaos tests simple and controlled, not complex [OK]

Common Mistakes:

• Starting with complex failures too soon
• Running chaos only after failures happen
• Ignoring monitoring during tests

3. Consider a microservice system where a chaos experiment randomly kills one instance every 5 minutes. What is the expected immediate effect on system availability?

medium

A. System availability remains stable if redundancy exists

B. System availability drops to zero immediately

C. System crashes permanently after first kill

D. System automatically scales down instances

Solution

1. Step 1: Analyze the chaos experiment impact

   Killing one instance every 5 minutes tests resilience but does not remove all instances.

2. Step 2: Consider system redundancy

   If the system has redundant instances, killing one does not reduce availability immediately.

3. Final Answer:

   System availability remains stable if redundancy exists -> Option A

4. Quick Check:

   Redundancy keeps availability stable during chaos [OK]

Hint: Redundancy keeps system available despite instance failures [OK]

Common Mistakes:

• Assuming system crashes immediately after one instance killed
• Thinking availability drops to zero instantly
• Believing system scales down automatically

4. A chaos experiment script intended to shut down a microservice instance sometimes fails silently without stopping the instance. What is the most likely cause?

medium

A. The network is too fast for the script

B. The microservice is designed to never stop

C. The chaos experiment is running on a different system

D. The script lacks proper error handling and logging

Solution

1. Step 1: Identify why script fails silently

   Silent failures usually happen when errors are not caught or logged properly.

2. Step 2: Evaluate other options

   Microservices can be stopped; network speed does not cause silent failure; running on different system would cause errors, not silent failure.

3. Final Answer:

   The script lacks proper error handling and logging -> Option D

4. Quick Check:

   Silent failure = Missing error handling [OK]

Hint: Check error handling if chaos script fails silently [OK]

Common Mistakes:

• Assuming microservice cannot be stopped
• Blaming network speed for silent failure
• Ignoring script environment mismatch

5. You want to design a chaos engineering experiment to test how your microservices handle database latency spikes. Which approach best fits this goal?

hard

A. Inject artificial latency into database calls during tests

B. Disable monitoring tools to avoid false alerts

C. Increase the number of database replicas without testing

D. Randomly kill microservice instances during peak hours

Solution

1. Step 1: Understand the goal of testing database latency spikes

   The goal is to see how microservices behave when database responses are slow.

2. Step 2: Choose the best chaos experiment approach

   Injecting artificial latency simulates slow database calls directly, matching the goal.

3. Step 3: Evaluate other options

   Killing instances tests availability, not latency; increasing replicas without testing doesn't simulate latency; disabling monitoring hides important data.

4. Final Answer:

   Inject artificial latency into database calls during tests -> Option A

5. Quick Check:

   Test latency by injecting delays = Inject artificial latency into database calls during tests [OK]

Hint: Inject delays to test latency, not kill instances [OK]

Common Mistakes:

• Confusing instance failure with latency testing
• Adding replicas without testing effects
• Turning off monitoring during chaos