retrystorm · Learn · Interview practice · Glossary · Components

Home › Reference › Components

Components

The building blocks the simulator offers, with their settings.

  • App server: Multi-replica compute with bounded concurrency and queue.
  • Message queue: Stores each job and acknowledges at once; workers take the jobs later, and failed ones are retried.
  • Topic: Takes each published message once and puts a copy on every subscriber's own backlog, so a slow subscriber only delays itself.
  • Stream: An ordered log split into partitions. Each consumer group reads every message at its own position, in order within a partition, and a message is kept until retention ends, not until it is read.
  • Connection gateway: Holds each client's connection open for the whole session on a lightweight slot. Handshakes and heartbeats take the instance's cores, and a crash drops every connection at once.
  • Worker: Takes jobs from a queue and does them in the background, a few at a time on each instance.
  • Cache: In-memory LRU cache sitting between app server and store.
  • CDN: Edge cache close to users. Cached reads are answered at the edge; misses and writes travel to the origin. By default a write purges the cached copy; with on_write set to ttl_only the edge keeps serving it until the TTL runs out.
  • Client: Generates open-loop or closed-loop load with read/write mix.
  • ID generator: Generates short IDs for writes.
  • KV store: Throughput-provisioned KV store with RCU/WCU throttling.
  • Object storage: Durable storage for files of any size. Nothing to size and no bandwidth limit, but every request takes tens of milliseconds and is billed.
  • Load balancer: Spreads requests across downstream instances. Each replica of an app server is its own target, so the algorithm decides which replica serves each request.
  • Rate limiter: Lets through at most a set number of requests per second, overall or per client, and turns the rest away at once with a 429.
  • Circuit breaker: Watches how the one component behind it answers. When too many calls fail or run slow it opens and turns requests away at once, then lets a few probes through after a cooldown to see if it has recovered.
  • Passthrough: Forwards every request to its single downstream; useful for smoke tests.
  • Relational DB: Primary + optional read replicas with bounded connection pools.
About · Contact · Privacy · Terms of use