Netflix open-sourced Chaos Monkey in 2012 and kicked off a whole discipline. The idea: inject failures deliberately to find weaknesses before real outages do.
Most developers interpreted this as "only for Netflix-scale infrastructure teams" and moved on. That's a mistake. The chaos engineering techniques that prevent the most real-world incidents are available to any team with a mock API and an afternoon.
The incident pattern
It goes like this: you ship a feature. It works in staging. In production, an upstream service has a bad day — maybe a 503 rate of 5–10%, maybe high latency rather than failures. Your frontend was never tested against these conditions. It shows a blank screen. Support tickets arrive.
The fix is usually trivial (add an error state, implement a retry). The damage is real: user trust, reputation, support time.
What practical chaos testing looks like
You don't need to randomly terminate servers. You need to inject HTTP errors into your mock API at a configurable rate and test your frontend against that mock.
In moqapi.dev, this is a slider in the mock API settings. Set error rate to 20%, pick error codes (500, 503, 429), and use your UI for 5 minutes.
You'll find unhandled error states in the first 3 minutes. Blank screens. Infinite spinners. Forms that submit silently and do nothing on failure.
Fix them. Ship them. Your feature is now resilient by construction, not by accident.
The Four States pattern
Every UI component that fetches data should have four states: loading, error, empty, content. Chaos testing enforces this. After one session, you'll write it by default for every new component. That's the cultural shift chaos engineering is supposed to produce — and it doesn't require a dedicated SRE team to get there.
Top comments (0)