Mo Sharif
← ~/work

System Design Learning Through Editable Models

Recognizing a message queue in a diagram is not the same as knowing when a system needs one.

The learning work in Codelit grew from that gap. I want the reader to move from “I know that pattern” to “I can explain why it belongs here.”

An editable architecture gives a lesson something a static picture cannot: a decision the learner can change.

Remove a replica. Add an asynchronous boundary. Change the partition key. Then explain what improved, what became harder, and which assumption supports the trade-off.

The graph does not measure latency or prove reliability. It makes the dependency visible so the learner can reason about what should be measured.

ExerciseThe reasoning it asks for
Remove a dependencyWhich operations can still finish?
Add a cacheWhich reads tolerate staleness?
Split a serviceIs the new boundary worth the coordination cost?
Change data placementWhat happens to consistency and recovery?
Reduce the budgetWhich requirement can change, and which cannot?

A challenge should state assumptions and invite more than one defensible answer. “Make it scale” is too vague unless the workload and service goals are part of the exercise.

The template library provides reference patterns and company-inspired examples. These are teaching models assembled from public material, not privileged views of another company's current production system.

A useful explanation names what is known, what is simplified, and what would require investigation. The system-design patterns article takes that approach.

The sign of progress is not that a learner can reproduce the reference diagram. It is that they can defend a different one.

Can they identify a failure mode? State a recovery objective? Explain why a simpler option is enough? That is the judgment behind the interview rubric, too.

A useful learning check asks the reader to explain an unfamiliar variation, not repeat the example. That is how the exercise moves from recognizing a pattern to making a decision with it.

Read a topic in the Codelit learning collection, then inspect a related architecture and change one constraint. Write down the trade-off before asking the model for its answer.

The aim is not to memorize more boxes. It is to become more deliberate about which boxes the system needs.