Why static diagrams fail: simulating an e-commerce checkout flow in Robust Design

It’s time we move on from static diagrams as the primary reference for demonstrating system design concepts. Sure, it makes sense to use it as a rapid proof of concept, but it fails when you genuinely want to understand how the system behaves. We have online resources to help you run and simulate code and provide concrete proof that it works, and it’s time we have one for system design. You could draw a diagram with a line to the load balancer, another to the server, and another to the database, but it doesn’t fully show what’s happening. We should be able to simulate, verify, and debug the system with minimal effort before we build it. It doesn’t make sense to create a system solely from a diagram.

As coding becomes more accessible, the shift will move toward system design. Entry-level roles will now be required more often to understand system design concepts and build systems. Being able to code alone is not enough; we also need tools that help those who are just starting to understand the ins and outs of a system entirely.

Robust Design solves this problem for both experienced and entry-level engineers. With Robust Design, you’ll be able to fully design the flow of how a system should behave and the flow of requests. After creating your system, you can simulate it to obtain real-time results rather than drawing a diagram. Worried about load during traffic hours? Add a load balancer and simulate it. Want to see how async request works with a server? Add a message queue and see how it affects the response time.
Here’s an example of Robust Design applied to a simple e-commerce system design flow.

To first design this system, we need to define the process.
First, we have three requests:

1. We need to allow users to check their inventory -> /inventory/check
2. We need to allow users to order and check out an item -> /orders/checkout
3. We need to allow users to pay for items -> /payments/process

Next, we need to route each request to the appropriate service. We route these requests through a load balancer using path-based routing. Finally, each request is saved to the database, or we retrieve data from it if the request is GET.

Now comes the fun part, simulating it. We can simulate each request individually by connecting it to the load balancer and clicking Run Simulation; we’ll then see the request flow. We’ll do that for all three and confirm that the design actually works and is valid. After this, we’ll then proceed to build the system. Diagrams alone cannot give you this confirmation. It’s time we innovate and develop better methods for designing systems.

robustdesign.io