I wanted a system-design lab that could prove me wrong

When I practice system design, the final diagram often feels unsatisfying. Sure, you can draw a load balancer, connect PostgreSQL to your application servers, and add a private subnet, but the diagram doesn't prove those components actually exist in the real system. That's the concept that drove the creation of Torollo, a system that treats the running system as the ultimate arbiter of your architectural assumptions.

The project centers on a local system-design lab where you build your architecture visually, with each canvas node backed by actual Docker resources on your machine. If you add a server, a container appears. Network boundaries? Torollo handles real Docker networking under the hood. The roadmap then validates the running environment, not just the diagram's appearance.

For instance, one free roadmap guides you through building a resilient three-tier application, progressively adding a load balancer, multiple web servers, network restrictions, and failure scenarios. One step involves isolating PostgreSQL from the load balancer. Torollo checks if the connection is truly blocked. This loop became the most crucial aspect of Torollo: You build something, make an assumption, and let the runtime prove whether the assumption holds true.

The canvas is just one layer. The React-based frontend, built with React, TypeScript, and React Flow, communicates with the backend, powered by Node.js, Express, TypeScript, and Dockerode. However, a clear separation exists between what the canvas declares exists and what Torollo can actually observe. If the frontend claims a server exists, the validator must verify its container is indeed running.

If your architecture claims database reachability, Torollo can test that connection. Even when an exercise asks you to create a table, the validator can inspect PostgreSQL state. If the task involves Redis, the validator can examine actual Redis data. The idea was to make Torollo more than just a graph editor with a green checkmark.

It needed to disagree with the diagram when necessary. Docker networking posed significant challenges. Some Torollo labs utilize Docker bridge networks, routing, NAT, and iptables rules to simulate various configurations. This complexity introduced the need for capabilities that a rootless Docker daemon cannot provide. Initially, I attempted to hide these details from learners, but I realized it was the wrong approach.

Torollo aims to make infrastructure behavior tangible, and ignoring the underlying environment would hinder that goal. Now, the CLI includes the `npx torollo doctor` command, which checks the Docker environment, ports, and runtime requirements, providing explanations and guidance before you waste time debugging an exercise your machine can't execute.

Don't mistake Torollo for a fake cloud provider. While the project uses containers, databases, load balancing, queues, caching, and networking, it doesn't aspire to replicate AWS locally. Its narrower goal is to take an architecture concept and make enough of it real that you can be wrong about it. If you declare a database isolated, there should be a way to test that claim.

If you introduce a cache, it should contain real data. If a worker is supposed to process a queue, there should be an actual worker and queue involved. If a failure is part of the exercise, something should genuinely fail. The local environment is meant to make the consequences of the architecture visible, not to pretend Docker on a laptop mimics production infrastructure.

What Torollo currently offers includes three free roadmaps: a resilient three-tier application, Redis cache-aside, and Redis queue workers. The roadmap format is JSON, allowing exercises to be easily editable. The core is MIT licensed and runs locally, requiring Node 18+, Docker, and no account registration. You can find the repository at https://github.com/Derssa/Torollo.

The next question I aim to answer is: Where does making the runtime real improve system design learning, and where does it start creating the wrong mental model? While a local Docker environment enhances aspects like PostgreSQL privacy, it's crucial to recognize that it can't fully replicate IAM, managed services, cloud control planes, real latency, production observability, or regional failures.

Thus, the challenge remains: Where does enhancing the runtime's realism improve system design learning, and where does it risk fostering an incorrect mental model?