What Cricket Taught Me About System Design

Our team once lost a close cricket match by three runs.

The annoying part was that we did not lose because of one impossible shot or one unlucky ball. We lost because our field placement was wrong for too long. The batter kept finding the same open space, and we adjusted too late.

After the match, I kept thinking about how familiar that felt.

Bad systems often fail the same way. Not all at once. Not because every part is broken. They fail because work is distributed poorly, one area gets overloaded, and nobody adjusts quickly enough.

Roles Matter

In cricket, roles are clear. Bowlers bowl. Batters score. Keepers protect behind the stumps. Fielders cover space.

If everyone tries to do everything, the team becomes confused.

Software systems have the same problem. A service that handles payments should not also manage search, authentication, and analytics. Clear boundaries make systems easier to reason about. When something breaks, you know where to look.

The lesson is simple: specialization is useful, but only if the pieces still work together.

Field Placement Is Load Distribution

Field placement is about predicting where pressure will go.

If a batter keeps hitting through cover, the captain moves a fielder there. If a new batter is weak on one side, the field changes again. The team is constantly redistributing attention.

Load balancing follows the same instinct. Requests should not pile onto one server while others sit idle. Traffic patterns change, and the system has to respond.

The analogy is not perfect, but it helped me understand the goal: do not let pressure concentrate in one place for too long.

Captains Think in Systems

A captain does not play every role. They watch the whole match.

They decide when to change bowlers, where to move fielders, and when to take risks. Good captains notice patterns before everyone else does.

That reminds me of system architecture. The job is not only writing code. It is understanding how the parts interact, where bottlenecks might appear, and what tradeoffs the team is making.

The bigger the system, the more important that view becomes.

The Scoreboard Is Observability

A captain cannot adjust a match they cannot read. The score, run rate, overs remaining, bowling figures, and fielding patterns are all signals about the state of the game. None tells the whole story, but together they make a decision possible.

Logs, metrics, and traces serve a similar purpose in software. CPU usage might reveal pressure, an error rate might show failure, and a trace might locate the slow dependency behind both. Without those signals, moving traffic or scaling a service is just another guess.

The lesson is not to measure everything. It is to collect the signals that help the team decide what to change.

Failure Is Part of the Game

Cricket has dropped catches, bad calls, rain delays, injuries, and pressure moments. A good team expects disruption.

Reliable systems need the same mindset. Servers fail. APIs time out. Traffic spikes. A system that assumes everything will work perfectly is fragile by design.

Resilience is not about avoiding every failure. It is about making sure one failure does not take everything down.

Small Optimizations Add Up

Everyone remembers sixes, but a lot of matches are won through singles, doubles, dot balls, and good fielding.

Systems are similar. Caching, indexing, async queues, smaller payloads, and cleaner queries are not always dramatic on their own. Together, they change how the system feels.

Good engineering often looks boring from the outside because the best improvements remove friction instead of creating drama.

Where the Analogy Ends

Cricket helped the ideas stick, but it is not an architecture diagram. Players improvise and get tired; server replicas are usually designed to behave alike. A captain can change a field in seconds, while moving a system boundary may take months. Team roles overlap in ways service boundaries should not.

That difference is useful too. An analogy should make the first question easier to ask, not replace the engineering needed to answer it.

Why This Analogy Stuck

I started using cricket examples while explaining system design ideas to friends. At first it was just a convenient comparison. Then I realized it actually helped me think.

Cricket made the abstract ideas more physical:

• roles became players
• load balancing became field placement
• resilience became adapting after a wicket
• optimization became taking the easy runs consistently
• observability became reading the scoreboard before moving the field

System design can feel intimidating because the words sound big. But a lot of it comes back to the same questions teams answer in sports: who owns what, where is the pressure, what happens when something fails, and how do we keep improving?

That is why the analogy stayed with me.

— Maruf