Client

Every design starts and ends with a client: the program that sends the first request and waits for the last byte of the answer. In the playground, client nodes are where traffic is born — the load profile (smoke, load, stress, spike, soak, breakpoint, chaos) decides how many requests per second leave them. In BoxOffice, the clients are the fans' browsers and the mobile app: on a normal day they browse the catalog; at 10:00 on a flash-sale day, 2 M of them press "Buy" in the same minute.

Thinking about the client is not a formality. Where the client is (latency to your edge), what it can do (cache, retry, hold a connection open) and how it behaves under failure (does it retry immediately? does the user hammer F5?) shapes the whole design behind it.

flowchart LR
    B[Client<br/>browser / SDK] --> DNS
    M[Mobile<br/>iOS / Android] --> DNS
    DNS --> CDN
    CDN --> LB[Load Balancer]
    LB --> APP[App Server]

Client

What it is. The generic client: a web browser, a command-line tool, another company's backend or a load-testing tool such as k6. It opens connections (TCP + TLS, or QUIC), sends HTTP requests and waits for responses. It sits outside your control — you cannot patch it, you cannot trust it, and it may be on the other side of the planet.

When to use.

• As the entry point of every playground design: the client node is the workload (requests per second, read/write mix, key popularity).
• To reason about the user-perceived latency: the number that matters is measured at the client, including DNS, TLS handshakes and the round trips to your edge.
• To decide what can be pushed to the client: static assets cached by the browser (Cache-Control), client-side rendering, idempotency keys generated by the client, exponential backoff in the SDK.

When not to (or watch out).

• Never put business rules or secrets that need to be trusted in the client: prices, seat availability and authorization must be validated on the server.
• Do not assume clients behave: a "Buy" button without debounce, a retry loop without backoff or a scraper bot can multiply your load.
• Do not size the system from the average client; size it from the peak (flash sale) and the worst network (mobile 3G in a stadium).

Key numbers.

Failure modes.

• Retry storms — clients (or users pressing F5) retry immediately after errors and multiply the load during an outage → exponential backoff with jitter in the SDK, Retry-After headers, a waiting room.
• Thundering herd at a fixed time — every client wakes up at 10:00:00 → randomized start, queue-based admission (waiting room), pre-warmed caches.
• Duplicate submissions — double click or timeout + retry creates two orders → idempotency keys generated by the client and deduplicated by the server.
• Stale client caches — the browser keeps an old JavaScript bundle → content-hashed file names, short TTL on the HTML.
• Malicious clients — bots, credential stuffing, scalpers → WAF, rate limiting, CAPTCHA/proof of work, authentication.

In the playground. The client node is a traffic source, not a server: it has no capacity. Arrivals per tick follow a Poisson process whose rate λ(t) comes from the load profile and the target RPS in the toolbar. Its main parameters are readRatio (fraction of reads; the toolbar default is 0.9), zipfS (key popularity skew, default 0.8, used by caches and partitions to create hot keys), botShare (extra bot traffic, default 0) and timeoutMs (the user's patience, default 30 s). The latency percentiles and error rate shown in the metrics panel are measured from the client's point of view. Every scenario starts here; good first ones: monolith, scale-out, flash-sale.

Real products.

Learn more: Intro › Requirements · Estimation › Numbers · Edge › Protocols · Performance › Load testing · Hands-on 2

Mobile

What it is. A native application (iOS, Android) or a mobile web app on a phone. It is a client with extra constraints: the network changes all the time (Wi-Fi → 4G → no signal in the stadium tunnel), the battery is precious, the app version in users' hands may be months old, and the operating system can kill it at any moment. In exchange it can store data locally, work offline and receive push notifications.

When to use.

• When the product needs push notifications (BoxOffice: "your tickets are ready", "the gates open in 1 hour").
• When the experience must survive bad networks: tickets stored on the device and shown offline at the gate (QR code).
• To model a second traffic source with a different mix: mobile clients usually make more, smaller requests and reconnect often.

When not to (or watch out).

• Old app versions live for a long time: never break an API used by a shipped app; version the API and keep backward compatibility.
• Do not chat with the backend: each request on a mobile network costs latency and battery → batch calls, use a BFF (Backend for Frontend) that returns exactly what one screen needs.
• Do not ship secrets inside the app binary (API keys can be extracted); use OAuth 2.1 with PKCE (Proof Key for Code Exchange).

Key numbers.

Failure modes.

• Connection drops mid-request — the app does not know if the purchase succeeded → idempotency key + a status endpoint to query ("did order X go through?").
• Reconnect storms — after a network or backend outage, millions of apps reconnect at once → randomized reconnect delay with exponential backoff and jitter.
• API breaking change — an old app version crashes → API versioning, contract tests, minimum supported version.
• Clock skew on the device — the phone's clock is wrong, tokens look expired → validate time on the server, use server timestamps.
• Push provider failure or throttling → treat push as best effort, keep the information available in the app and by e-mail.

In the playground. mobile is a traffic source just like client, with the same parameters (readRatio, zipfS, botShare) but a shorter default timeoutMs (15 s instead of 30 s), driven by the same load profile. Use it next to a client node to model two populations with different read/write mixes or to route them through different paths (for example, mobile through an API Gateway acting as a BFF). Scenarios: chat, ride-sharing, notification-system.

Real products.

Learn more: Edge › Protocols · Compute › API styles · Network & security › Identity · Case study: chat · Case study: notification system