Bottlenecker
by Arkynate Labs · v2.3.3

Component Reference

Six node types and connection edges to model any distributed system — with latency, error rates, queue backlog and retry amplification built in.

Simulation Features
📉Error Rate Modeling
Each node has a configurable baseline error rate. A node past capacity serves only its capacity and sheds the rest as errors, and only successful requests continue downstream — so one saturated tier never fakes a bottleneck behind it.
errors = 1 − (min(in, capacity) ÷ in) × (1 − baseline)
⏱️Latency Modeling (M/M/1)
Latency grows non-linearly as utilization approaches capacity (M/M/1) and is unbounded at 100%. The bar shows the mean request latency, weighted by traffic along the synchronous path, and the critical path — the slowest path that carries traffic.
latency = baseLatency / (1 − utilization)
🔁Retry Amplification
Retries multiply the load on the target by the expected number of attempts. Overload raises the error rate, which raises attempts again, so the engine iterates the whole graph to a steady state (and warns if it cannot settle).
attempts = 1 + e + e² + … + eʳ
🧪Stress Test
The Stress Test runs your diagram at 0.5×, 1×, 2×, 5× and 10× of configured load, shows each component's exact headroom, and finds the maximum sustainable load and which component reaches 100% first.
Components & Edges
⚡
Load Generator
Represents the source of incoming traffic to your system. Every diagram should start with a Load Generator.
Configuration Fields
Label
Display name on the canvas
Output QPS
Queries per second emitted from this source. The Stress Test multiplies this value across 0.5×–10× runs.
💡
Use multiple Load Generators to model different traffic sources (e.g., web users vs. batch jobs). Multiply all generators at once using the Stress Test button.
⚖️
Load Balancer
Distributes incoming traffic across its downstream connections — equally by default, or weighted with per-connection percentages.
Configuration Fields
Label
Display name on the canvas
Max QPS
Maximum throughput before this node becomes a bottleneck
Error Rate (%)
Percentage of requests this node fails to forward. Past capacity it also sheds the excess as errors.
Base Latency (ms)
Processing latency at this node when not under load. Default: 2 ms. Rises under load via the M/M/1 queueing model.
💡
Connect it to several servers to model Nginx, HAProxy, or AWS ALB. To weight targets, set a percentage on each connection. A saturated load balancer passes on only its capacity, so the servers behind it look idle. Set a base latency of 1–5 ms to represent real forwarding overhead.
🖥️
Server / API
Represents an API server, microservice, or compute node. Scale horizontally by setting multiple instances.
Configuration Fields
Label
Display name on the canvas
Max QPS (per instance)
Max throughput of one instance; capacity = Max QPS × Instances
Instances
Number of replicas running in parallel
Error Rate (%)
Baseline % of requests that result in errors (e.g. 5xx). Past 100% utilization the node also sheds the excess: total errors = 1 − (capacity ÷ incoming) × (1 − baseline).
Base Latency (ms)
Response time at this node under no load. Default: 50 ms. Grows as base ÷ (1 − utilization) and becomes unbounded at 100%.
💡
Set instances > 1 to model a horizontally-scaled fleet. Total capacity = maxQPS × instances. Assign a realistic error rate (1–5%) to see how downstream retries amplify your database load.
🗄️
Database
Relational or document store with separate read/write capacities and optional read replicas.
Configuration Fields
Label
Display name on the canvas
DB Type
postgres, mysql, mongodb, or redis
Max Read QPS
Read queries per second per node; read capacity = Max Read × (1 + replicas)
Max Write QPS
Write queries per second on the primary — replicas do not add write capacity
Read Replicas
Additional read-only replicas (adds to read capacity only)
Read Ratio (%)
Percentage of incoming requests that are reads; the rest are writes
Error Rate (%)
Baseline % of queries that fail. Combine with retries on upstream edges to model retry amplification.
Base Latency (ms)
Query latency under no load. Default: 15 ms. Rises sharply as utilization approaches capacity.
💡
Databases are the most common bottleneck. Reads and writes are checked separately — utilization is whichever path is busier — so replicas fix read pressure but never write pressure. Add retries on incoming connections to observe retry storms: at a 15% error rate, 3 retries cost 1.18× the load, and once that overloads the database the rising error rate drives even more retries.
🗃️
Cache
In-memory cache layer (Redis, Memcached, or CDN). Intercepts requests based on hit rate and serves them locally.
Configuration Fields
Label
Display name on the canvas
Cache Type
redis, memcached, or cdn
Hit Rate (%)
Percentage of requests served from cache — only (100 − hitRate)% flow to downstream nodes
Max QPS
Maximum throughput of the cache node itself
Error Rate (%)
Percentage of cache operations that fail (e.g., evictions, OOM). Usually 0–1%.
Base Latency (ms)
Cache read latency under no load. Default: 1 ms.
💡
A high hit rate dramatically reduces load on downstream databases. Model cache warming by starting with a lower hit rate. Base latency of 1 ms reflects in-memory speed.
📨
Queue
Message queue or event bus (Kafka, RabbitMQ, SQS). Decouples producers from consumers and buffers load spikes.
Configuration Fields
Label
Display name on the canvas
Queue Type
kafka, rabbitmq, or sqs
Max Throughput
Messages per second per consumer
Consumers
Number of concurrent consumers processing the queue
Error Rate (%)
Percentage of messages that fail to be delivered or processed.
Base Latency (ms)
Publish latency seen by the producer. Default: 5 ms.
💡
Drain rate = Max Throughput × Consumers. Messages arriving faster than that build a backlog (msg/s) instead of failing, and only the drained rate reaches the consumer servers behind the queue. The queue ends the synchronous request, so the consumer side is left out of request latency. Set base latency to 5 ms to model Kafka publish latency.
→
Connection (Edge)
Directed connection between two nodes. Controls how QPS flows from source to target, and how many times the caller retries on error.
Configuration Fields
Endpoint Label
Optional label shown on the edge (e.g. "GET /users")
Distribution Mode
absolute (QPS cap) connections are filled first, then percent connections take their share of what is left, then auto connections split the rest equally. Percentages above 100% in total are scaled down; with no auto connection, leftover traffic is reported as unsent.
Distribution Value
For percent mode: 0–100. For absolute mode: QPS value. Ignored in auto mode.
Retries on error
How many times the caller retries when the target returns an error (0–10). Absolute caps still hold after retries.
💡
Set retries > 0 on connections into nodes that fail to observe retry amplification. Each request costs 1 + e + e² + … + eʳ attempts, where e is the target's total error rate (configured + overload): a 10% error rate with 3 retries means 1.11× the load. If that pushes the target past capacity, e rises and the simulator solves the loop to its steady state.

Ready to model your system?