When you first start studying system design and distributed systems, almost everything is taught through static boxes and arrows.
Someone draws a Load Balancer, an App Server, a Redis Cache, and a Database, and says: "Put a cache in front of the database to handle read traffic, and add retries for fault tolerance."
On paper, it makes total sense. In practice, systems behave in weird, non-linear ways under load:
- What happens when your 92% cache hit rate drops for 30 seconds?
- What happens when a caller times out and retries, while the downstream service keeps processing the abandoned request anyway?
- How quickly do queues explode once traffic crosses steady-state capacity?
As I started diving deeper into caching, replication, message queues, and fault tolerance, I realized I couldn't really internalize these concepts just by reading about them. I needed to experiment with them.
That's why I started building ShardCraft.
Turning Theory into Interactive Labs
My goal with ShardCraft is to take complex engineering concepts and turn them into interactive simulations where you can actually see how systems behave under load, failure, and growth.
Even building the simplified mathematical models for the site has taught me a ton—having to think through Poisson request arrivals, exponential service-time tails, retry backoff/jitter, and the difference between async slot-freeing vs. thread-per-request blocking.
Learning in Public (Mistakes Included)
I'm definitely not claiming to be a distributed systems expert. I'm building this to learn, ask questions, test my assumptions, and share what I discover along the way.
Through this series and on the site, I'll be sharing:
- Deep-dive explanations into how real systems scale and fail
- Interactive labs where you can break architectures in your browser
- Corrections & iterations—the things I modeled wrong at first before figuring them out
Come Break Some Systems With Me
Whether you're just starting out with system design or you've been firefighting production incidents for years, I'd love to learn with you (and from you!).
👉 Explore the guides and interactive labs here: shardcraft.dev
If you take a look at the simulation notes or labs, let me know what you think—or drop a comment below on what distributed systems topic you'd love to see simulated next! 🚀
Top comments (1)
The retry-storm bullet is the one that turns an abstract lab into something that maps to production reality. Diagrams never show a caller timing out while the downstream keeps processing. I would suggest adding a lab where the cache-hit rate slider decays slowly, since that gradual degradation is exactly what teams miss on paper.