Ticker

Both services are free, official open-source images — postgres:16 and redis:7 — so the whole backend runs locally with no account, quota, or card. Compose gives every learner the same versions and a clean reset (docker compose down -v). Your server reads DATABASE_URL and REDIS_URL from the environment, so the identical build runs locally, in CI, and in the cloud — only the connection strings change.

Costs nothing. redis:7 and postgres:16 are open-source images; XADD, XREAD, and consumer groups are core Redis, not a paid tier.

A dashboard that shows live prices needs three things from its data layer: a change feed (tell me when something changed), fan-out (tell everyone at once), and replay (tell me what I missed while I was away). Redis pub/sub gives you the first two and not the third: it is fire-and-forget and at-most-once, so a tab that was asleep when a price changed never learns about it. Redis Streams are an append-only log — every entry gets a stable, ordered id (<ms>-<seq>), entries persist until you trim them, and XREAD can start reading from any id to replay the gap. That third property is the whole project: it is what lets a briefly-offline client catch up exactly instead of refetching everything.

Postgres is the durable truth, but a request/response store cannot push or replay, which is precisely why a realtime store sits in front of it. The Redis track introduces pub/sub from redis-cli and mentions Streams; here we make Streams load-bearing.

The whole project rests on two Stream behaviours; feel them by hand now so the later server steps are a re-implementation of something you have already seen, not an act of faith. In window A, XREAD BLOCK 0 parks — it returns nothing until window B appends an entry, then wakes with that entry and its id. That is the live fan-out path. Then reconnect: call XREAD again but start from an explicit id you noted earlier, and Redis hands back every entry after it immediately — that is replay-from-id, the reconnect path. Two commands, both halves of the build, in your terminal in under a minute.

Money is BIGINT cents, never float. CHECK (stock >= 0) and CHECK (price >= 0) make impossible data unwritable by any client. The new idea versus a plain catalog is version: an integer you bump on every write. It lets two things work later — a stale write is rejected by a conditional UPDATE (optimistic concurrency), and a replayed event is applied idempotently by comparing versions. updated_at gives every change a wall-clock for the dashboard.

The Compose file mounts no init script, so the table does not appear by magic — you load db/schema.sql yourself once, after docker compose up. The connection string’s user is postgres (the image’s default superuser, because Compose set only POSTGRES_PASSWORD and POSTGRES_DB); if you ever set POSTGRES_USER, update DATABASE_URL to match. After this load, GET /products will return exactly the three seed products the rest of the build assumes.

Every mutation produces exactly one event, and the event carries enough state to apply it without reading anything else: { product_id, price, stock, version }. You append it with XADD warehouse:1 * ...; Redis assigns the ordered id <ms>-<seq> and returns it.

Keying a Stream per warehouse (warehouse:{id}) is the general design — it keeps each feed small and lets a dashboard subscribe to just the warehouse it watches. To keep this build focused, we commit to a single warehouse: warehouse:1 is the fixed key everywhere — the write routes XADD to it, GET /stream tails it, and the dashboard reads it. (Generalising to a request-supplied warehouse — GET /stream?warehouse=N, write routes keyed by the product’s warehouse — is a clean exercise; if you do it, make every step use the same id, or a dashboard keyed to warehouse:2 will silently see nothing.)

Because the event is self-contained and the version is monotonic, a client can apply events from anywhere — fresh, replayed, or duplicated — and still converge (you lean on this in the idempotency step). One Redis fact to internalise now: Stream field values are strings, so encode numbers as decimal text and parse them on the way out.

pgx is the standard Postgres driver for Go and github.com/redis/go-redis/v9 the standard Redis client; both take a context on every call. The server is deliberately one process doing three jobs — REST writes, an SSE stream, and serving the static public/index.html — so a learner runs one binary and opens one URL. Always pass r.Context() and use parameters ($1); never string-concatenate SQL.

Hono is a tiny web framework that speaks the Web Request/Response API, so the same app runs on Bun, Node, and the edge. Bun is a fast, batteries-included runtime whose built-in server reads the app’s default export. You’ll use pg (node-postgres) for the durable store and the redis package (node-redis, pinned to v5) for Streams. Keep request handlers free of Node-only APIs so the app stays portable — exactly the discipline the TypeScript track builds.

One static-serving gotcha worth getting right now: Hono’s bun serveStatic({ root }) maps the request path to a file under root, so a bare GET / resolves to the directory and does not reliably auto-serve index.html the way Go’s http.FileServer does. The documented SPA pattern is a catch-all that points at the file directly — serveStatic({ path: "./public/index.html" }) — registered after your API routes. That keeps GET / returning the dashboard, so the page works identically on both backends.

This is the spine of the project. A write does two things: it updates the row in Postgres (the durable truth) and appends an event to the Stream (the thing watchers read). Do them in that order — Postgres commits first, so the Stream never advertises a change that didn’t actually happen. The UPDATE ... RETURNING price, stock, version hands you the post-write state in one round trip; you serialise exactly that into the XADD. Because the event id is assigned by Redis and is monotonic, the Stream is now the canonical order of changes — which is what makes fan-out and replay agree across every client and every server instance.

This step gives you the two store operations — setPrice(id, newPrice, expectedVersion) and sell(id, qty) — as the SQL + commit-then-XADD order. The HTTP routes that call them (PUT /products/{id}/price, POST /products/{id}/sell) are the very next step, so the dashboard has real endpoints to hit.

The dashboard’s slider PUTs {price, version} and its Sell button POSTs {qty}; without these routes both 404. Each handler is thin: parse the JSON body and the {id} path value (Go 1.22’s r.PathValue("id")), call the matching store op from the write path, and translate the result to the HTTP contract. The XADD already lives inside the write path, so a successful route automatically fans the change out.

The subtle part is the zero-row case. The conditional UPDATE ... WHERE id=$id AND version=$expected (or ... AND stock>=$qty) returns no row for two different reasons: the version was stale / the stock was insufficient (the row exists), or there is no such id at all. pgx.ErrNoRows from the UPDATE’s RETURNING cannot tell them apart — so on zero rows you re-SELECT the row by id alone. If that re-SELECT finds the row, it is a real conflict / out-of-stock: return 409 with the current {price, stock, version} so the client rebases to the live value. If the re-SELECT finds nothing, the id is unknown: return 404. One extra indexed PK lookup, only on the cold failure path, is what makes the two errors distinguishable — a route that always returned 409 could never surface a genuine bad id.

The dashboard’s slider PUTs {price, version} and its Sell button POSTs {qty}; without these routes both 404. Each Hono handler reads the :id param (c.req.param("id")) and the JSON body (await c.req.json()), calls the matching write-path op, and maps the result to the contract. The XADD lives inside the write path, so a successful route fans the change out automatically.

The zero-row case carries two distinct errors, exactly as in the Go server. The conditional UPDATE matches no row when the version is stale / stock is insufficient (the row exists) or when there is no such id — result.rowCount === 0 (node-postgres) cannot tell which. So on a zero-row result, re-SELECT the row by id: if it comes back, return c.json(currentRow, 409) (a real conflict or out-of-stock, the client rebases to the live value); if it comes back empty, return c.json({ error: "not_found" }, 404). The write-path op returns both signals (e.g. { row, conflict, found }) so the handler stays a thin mapper — and the two backends return byte-identical 404/409/200 responses.

Many operators may edit the same product. Rather than lock rows, you let writers race and detect the loser: the write carries the version the client last saw, and UPDATE ... WHERE id = $id AND version = $expected bumps the version only if nothing changed underneath. Zero rows means someone else won the version race; the write-path step already covers how a zero-row result re-SELECTs by id to return 409 (row present) versus 404 (no such id). What this step adds is the rebase: because the 409 body has the same shape as a change event, the client reconciles to the fresh value the same way whether it learns of it by conflict or by fan-out — so a stale write costs one retry, not a lock held across the edit. That makes optimistic concurrency cheaper than pessimistic locking exactly when conflicts are rare.

A sale decrements stock and, like every write, bumps the version and emits an event. The safety is one atomic statement: `UPDATE products SET stock = stock - $qty, version = version + 1 WHERE id = $id AND stock

= $qty. The stock >= $qty predicate *is* the guard: Postgres row-locks the matched row for the duration of the statement, so two clients racing for the last unit serialise — exactly one affects a row, the other matches none. The zero-row outcome then flows through the same disambiguation the [write-path step](#write-path) defines (re-SELECTby id →409 out_of_stockif the row exists,404if it does not). This is deliberately the same primitive Aurora uses, but here it is a single line, not the lesson: **[Aurora Commerce](/projects/aurora-commerce/)** spends a wholeBEGIN … COMMIT` making a multi-row checkout atomic; Ticker needs only this one guard and spends its energy on propagating the result of the sale to every watcher. Same guarantee, opposite emphasis.

Server-Sent Events is just a long-lived HTTP response with Content-Type: text/event-stream; you write id: <stream-id> then data: <json> then a blank line per event, and flush. The source of those events is XREAD BLOCK 15000 STREAMS warehouse:1 $, which parks the connection until the next entry is appended (or the block elapses), then returns it with its id. Because every server instance tails the same Stream, you can run N servers and they all deliver the same ordered events — the Stream, not the process, is the fan-out point, so horizontal scaling is free. Pass the id the client last saw (the next step wires Last-Event-ID) instead of $ to begin with replay. Flush after every write (http.Flusher) or the browser sees nothing until a buffer fills.

Hono’s streamSSE helper turns a handler into a text/event-stream response and gives you a stream object with writeSSE({ id, data }). The events come from node-redis xRead. One rule matters: a blocking xRead ties up its connection, so you must run it off your shared client. node-redis documents createClientPool() for isolating blocking commands; for a long-lived per-client stream the simplest correct choice is a dedicated connection via redis.duplicate() that you open on connect and close on disconnect — never the shared one your REST handlers use, or the whole app stalls behind the blocked read. Each connected client gets its own reader, loops awaiting the next event, advances its last id, and writes a frame. The id you start from is the Last-Event-ID header (replay) or $ (only-new).

Reconnect-and-replay works because of one shared rule — the unit of progress is the Stream id. The server already writes it as the SSE id: field; the browser’s EventSource automatically remembers the last id: it saw and, on an auto-reconnect, sends it back as the Last-Event-ID request header. So the client needs no bespoke bookkeeping for the live path — the platform does it. For a catch-up that must survive a full page reload, persist the last id yourself (e.g. localStorage) and send it explicitly. Either way the server’s job is identical: start reading just after the given id. Treat the id as opaque and monotonic; never try to compute the next one yourself.

You already pass Last-Event-ID into XREAD, and the elegant part is that no second code path is needed. XREAD BLOCK 15000 STREAMS warehouse:1 1718900000000-0 returns every entry after that id immediately (Redis ranges are id-ordered — the bounded block only matters once you have caught up to the live tail), so a client that was offline for ten seconds receives its seven missed events back-to-back, then the loop blocks ~15s at a time for the next live one. Two refinements make it production-honest:

1. Count the gap. The first XREAD batch after a reconnect is the missed set; emit a one-off event: replaying frame with its length so the dashboard can show Replaying N events. Guard it on a real (non-null) batch so a clean reconnect that lands on an idle timeout never flashes a count.
2. Handle a trimmed id. If the client’s Last-Event-ID is older than the Stream’s first retained entry (XINFO STREAM warehouse:1 exposes first-entry), the gap is unrecoverable from the Stream — send a one-off event: resync telling the client to re-GET /products for a fresh snapshot, then continue live. Replay restores deltas; the snapshot restores a baseline when the deltas are gone.

The block stays bounded here too (Block: 15 * time.Second, never Block: 0): once the backlog drains, this is the live tail again, so the same redis.Nil-on-timeout → keepalive → context-recheck cleanup applies.

The TypeScript path is the Go path in different syntax. The dedicated reader’s first non-empty xRead from a real Last-Event-ID returns the missed batch; you writeSSE({ event: "replaying", data: String(batch.length) }), stream the frames, advance lastID, and the loop then blocks ~15s at a time for live events. The trimmed-id case uses node-redis xInfoStream(stream) to read the oldest retained id — which node-redis v5 returns under the hyphenated key info["first-entry"].id, not info.firstEntry (that property is undefined, which would silently disable the whole resync branch). If the client’s id is older, write a resync event and let it re-GET /products. Compare the two ids component-wise on <ms>-<seq> (split on -, the ms as a number, then the seq as a number) — a string compare wrongly orders 5-2 after 5-10 and falsely resyncs once ten events share one millisecond. Keeping the two servers behaviourally identical is the point — a learner can swap backends and the dashboard cannot tell, including the same bounded block (BLOCK: 15000, never BLOCK: 0), the null-on-timeout keepalive, and the sse.closed/sse.aborted re-check that frees the duplicated connection when the tab closes.

Replay and live delivery can overlap — a reconnect might re-deliver an event you already applied, or two servers might both forward the same change. That’s fine if applying an event is idempotent. The rule: hold the current version per product, and when an event arrives apply it only if it is newer than the version you already show; otherwise drop it. Because version is monotonic per row, this collapses duplicates, tolerates out-of-order arrivals during the replay-to-live handoff, and means you never have to guarantee exactly-once delivery (which is expensive and, here, unnecessary). The same predicate works for snapshots: a snapshot is just a set of (id, version) baselines you apply the same way.

The payoff has to be something you see, so the dashboard is one static file the backend already serves at /. It uses two browser built-ins: fetch for the snapshot and writes, and EventSource for the live feed (it handles reconnect and Last-Event-ID for you). The render is a tiny reducer over the applyEvent rule from the last step. Open the file in two browser windows: drag the price slider in window A and window B’s number ticks within ~100ms; click Sell 1 and stock drops in both; when stock hits 0 the Sold-Out badge flips and a second window trying to sell the last unit gets a live out of stock toast — that’s the atomic guard, visible.

The whole point of durable realtime is invisible when everything is online — so surface it. EventSource fires onopen when connected and onerror when the connection drops (it then auto-reconnects, re-sending Last-Event-ID); listen to those for Live and Reconnecting…. Your server emits a custom replaying event with a count at the start of a reconnect, so addEventListener("replaying", …) shows Replaying N events while the gap drains, and the next live message returns you to Live. A resync event tells the dashboard to re-GET /products.

Now the money demo: open two windows, in DevTools set window B’s network to Offline, change prices and sell in window A for ten seconds, then bring B back Online — the pill reads Reconnecting…, then Replaying 7 events, the backlog fast-forwards, and B ends byte-identical to A. No gaps, no full refetch.

In-process fan-out (a Go channel, a Node EventEmitter) only reaches clients connected to that process, so it breaks the moment you run two instances behind a load balancer. Redis Streams sidestep this entirely: every instance runs the same XREAD BLOCK against the same Stream, so all of them see every event and forward it to their own SSE subscribers. There is no leader, no sticky sessions, no inter-node gossip — the realtime store is the coordination point. Write through instance A (:8080), connect a dashboard to instance B (:8081), and the tick still arrives. That is the property that lets this design scale from one box to many without changing a line of fan-out code.

A Stream you never trim grows without bound and eventually costs more RAM than the data is worth. Cap it at append time with approximate trimming — XADD warehouse:1 MAXLEN ~ 10000 * … — where the ~ lets Redis trim in efficient batches (a little over the cap is fine, and much cheaper than exact trimming). Trimming raises a question: what about a client whose Last-Event-ID is older than the oldest retained entry? That gap is unrecoverable from the Stream, which is exactly why Postgres holds the snapshot — current price, stock, and version for every product. The protocol is snapshot-first: a client always loads GET /products (the baseline), then tails the Stream from live; a reconnect replays the gap if it is still retained, or falls back to a fresh snapshot via the resync event if it is not. Snapshot = baseline truth; Stream = recent deltas; together they bound memory and guarantee no gaps.

Streams answer two different questions, and Ticker has been using only the first. The fan-out read you built — XREAD against warehouse:1 — gives every reader every entry: run N server instances and each one tails the same Stream independently, so each connected dashboard sees the full ordered feed. That is exactly what a live mirror wants, and it is why the multi-instance step scaled for free.

A consumer group answers the opposite question: distribute the work so each entry is processed once across a pool. XGROUP CREATE warehouse:1 workers $ creates the group; each worker calls XREADGROUP GROUP workers <consumer> COUNT N STREAMS warehouse:1 > and Redis hands different entries to different consumers (the > means “messages never delivered to this group”). Delivery is tracked, not fire-and-forget: an entry stays in the group’s Pending Entries List until the worker confirms it with XACK warehouse:1 workers <id>. XPENDING warehouse:1 workers inspects what is still un-acked, and XAUTOCLAIM warehouse:1 workers <consumer> <min-idle> 0 reassigns entries a crashed worker grabbed but never acked — that ack-and-reclaim machinery is the whole point of a group, and it is pure overhead for a mirror.

So the choice is load-bearing, not accidental. If you put the SSE servers in a consumer group, each change event would be delivered to one server, and only the dashboards connected to that server would tick — the other windows would silently miss it. Plain XREAD is correct here precisely because it does not distribute: every instance must see every event for the fan-out to be complete. Reach for a group when you want competing workers (a re-embed worker, an email sender, an audit sink) to share a backlog so each job runs once; reach for plain XREAD when every reader needs the whole feed. (A consumer-group-worker that processes each change exactly once is a natural future add-on — out of scope here.)

Unit tests with a fake Redis can’t prove ordering, blocking reads, or replay — those exist only in a real server. Point the test at the Compose stack: start the fan-out handler, connect subscriber S1, make a change, and assert S1 receives it within ~100ms with the right version. Then for replay: connect S2, record its last id, disconnect it, make K changes, reconnect S2 with Last-Event-ID, and assert it receives exactly those K events (the replaying count equals K) and ends with state identical to a fresh GET /products. Skip cleanly if the env vars aren’t set, so the suite still runs without infra.

The TS suite asserts the identical behaviour with bun test (or vitest): an SSE client receives a change within ~100ms, and a reconnect with Last-Event-ID replays exactly the missed events, ending byte-identical to GET /products. Running both suites against the same Compose stack is what lets the project claim, honestly, that the realtime store — not the language — carries the weight.

Nothing about seeing the project work requires the cloud — docker compose up is the whole demo. If you want a public URL, the server is a stateless container, so Cloud Run fits: it scales to zero and has a generous free monthly allotment. Redis Streams need a real Redis, and this design relies on blocking XREAD BLOCK, so self-hosting redis:7 (a tiny VM or container host) keeps it unchanged. One honest constraint to know: some serverless Redis offerings — Upstash’s free tier among them — support Streams (XADD / XRANGE) but not the blocking form of XREAD; on those you’d switch the reader to short-interval non-blocking polling (XREAD with no BLOCK, on a timer) instead. Postgres can be Cloud SQL or any managed Postgres. Only the three connection strings change; the binary and the dashboard are identical to local.

The change feed you already maintain is a perfect input for a cheap summary: pull the recent events with XRANGE warehouse:1 - + COUNT 200, and ask Gemini to return structured JSON — products trending toward sold-out, prices that moved more than a threshold, a one-line headline. Use responseMimeType: "application/json" with a responseSchema so the output is typed, not free text you have to parse. Keep the key server-side and expose GET /insights that the dashboard can show as an advisory banner. Crucially this is read-only: it suggests a restock or a price review, it never changes a price or places an order — the platform shows the way, it doesn’t act. Costs nothing: a free Google AI Studio key covers this.

Nothing about the server changes here. The Android app points at the identical /products and /stream endpoints the bundled public/index.html already calls; run the backend with docker compose up and the emulator reaches it at http://10.0.2.2:8080 (the Android emulator’s alias for your host’s localhost). The lesson is that the realtime protocol — snapshot-first, then an ordered SSE feed whose every frame carries a Stream id — is client-agnostic: a browser and an Android app reconcile against the same feed the same way. The one honest difference, which the next steps lean on, is that the browser’s EventSource auto-reconnects and resends Last-Event-ID for you, whereas a native SSE client does not — so on Android you own the reconnect-and-replay discipline. Costs nothing: the backend is the same local Docker stack, and the Android emulator ships free with Android Studio — no device, no account, no paid service.

To learn the UI toolkit itself, see the Jetpack Compose track; for the language, Kotlin.