How the SystemDecoder simulator works

Inputs and request flow

You connect components and configure inputs such as client request rate, component capacity, base latency, instance count, cache hit rate, and region. The engine propagates load through the connected graph and computes per-node results. Library demonstrations and guided lessons are teaching models with their own inputs; do not assume every module uses the same formula.

For a useful comparison, keep the traffic and topology constant while changing one variable. Record the original assumptions with the result. An improvement under one workload may disappear when a different component becomes the constraint.

Capacity, latency, and failures

Node results expose incoming load, effective capacity, processed or dropped traffic, and utilization where applicable. Load balancers distribute traffic, caches reduce downstream lookup demand, and queues model a processing boundary. Failed and partitioned components change the paths available to a request.

The core engine includes a load-adjusted latency term calculated as adjusted base latency × (1 + u²), where u is effective load divided by effective capacity, capped at 3. Component behavior, configured delays, and failure rules can affect the final result. This is a teaching curve, not a measured latency distribution or a p99 forecast.

Geographic delay uses a fixed illustrative region matrix. For example, the model assigns 20 ms within a region and 100 ms between US and EU regions. Real network conditions vary by provider, route, placement, and time. These values are assumptions, not current internet measurements.

Cost estimates

The cost model adds configured per-unit hourly costs. API and service components account for supported instance counts. Default unit costs are example values for comparing a design inside the tool; they are not a cloud provider’s price quote.

Before budgeting a deployment, use the provider’s current regional pricing and account for the services actually needed, including storage, data transfer, requests, support, backups, and operational work. A lower displayed simulator cost does not establish a lower total production cost.

What this model cannot validate

• Application correctness, transaction isolation, data durability, and security controls.
• Actual server performance, network variability, realistic tail latency, or provider SLAs.
• A company’s proprietary architecture. Named product guides demonstrate plausible patterns for a design exercise.
• Production readiness from a successful simulated run. Real systems need workload tests, failure tests, monitoring, and recovery exercises.

Reproduce a useful experiment

1. State a question, such as whether a cache protects the database during a traffic spike.
2. Record the graph, request rate, capacities, hit rate, and failure settings.
3. Run a baseline, change one input, and compare the affected components.
4. Share the design together with those assumptions and explain what would need measuring in a real system.

Guest share links work without sign-in and expire after ten days without a content edit. Saving a design to an account requires sign-in. Premium only raises cloud save and share limits; the learning models are free.

Start with the introduction to system design, the URL shortener guide, or a capacity planning guide.