Components · Traffic and compute

Presence service

Who is online and typing: heartbeats in, status out (Slack, WhatsApp).

Lesson
Coming soon
Zone
app
Place it
4 cr on the blank canvas, free inside a problem

At a glance

Did you know
Presence is a heartbeat: each client pings every few seconds, and a status flips to away when the pings stop.
Rule of thumb
Fan presence out through pub/sub by channel, never by polling every user.
Watch out
Heartbeat storms after a reconnect; stale status when it falls behind.

Its settings in ScaleMySystems

What you can change on it in the lab, and what each number does.

Concurrency (slots)
Calls it can work on at once (per instance when autoscaling). Needed slots ≈ calls per second × seconds each takes. Extra calls wait in the queue, then are rejected.
Queue capacity
Calls allowed to wait for a free slot. A bigger queue absorbs bursts but adds waiting time; 0 rejects straight away.
vCPU
CPU cores available. Needed ≈ calls per second × CPU per request ÷ 1000. Above about 90% busy it slows down and may crash.
CPU per request (ms)
CPU time each call burns. Part of what the component is; make the code cheaper to lower it.
Latency (p50) (ms)
Typical time one call takes here, before any calls it makes itself. Slots are held for this long.
Latency (p99) (ms)
The slowest 1% of calls. Callers must set their timeout above this or they cut off healthy calls.
Timeout to dependencies (ms)
How long it waits for each call it makes before giving up. Set it above the dependency’s p99 but low enough that a dead dependency does not hold every slot.
Error rate
Share of calls that fail on their own (bugs, declines, flaky tools). An agent that calls it on every step multiplies this.
Quota (req/min)
Calls allowed per minute (an API key or provider limit). Calls over it get 429s. Needed = calls per second × 60, with headroom.

Problems that start with it

  • Slack: from launch build to real traffic Slack as first built: channel history read straight from MySQL with no cache, no read replicas, and the message, history and presence services, fan-out workers and search at an eighth of their real size. 5,000 requests a second: 45% reading history, 40% sending messages that fan out to channels, search and push, 15% presence. Messages and history time out.

Full lesson coming soon

Lessons are being added one component at a time: how it works, its settings, a live exercise to break and fix it, interview questions and a short check. See the Circuit breaker lesson for what one looks like.