A live photo wall for parties: WebSockets as a doorbell, REST as the truth

Ondravan — Sat, 24 Oct 2026 06:56:29 +0000

At a wedding or a party, there is usually a TV or a projector doing nothing. We wanted it to show every guest's photos as they are taken. That is the "live slideshow wall" in Fondays, a shared photo album app for events, and it turned out to be a nice small exercise in keeping real-time features honest.

Here are the rules we ended up with.

1. The socket is a doorbell, not the record

The wall opens a WebSocket and gets a short message whenever a photo lands. The message is a notification. The photos themselves always come from the normal REST API.

That one decision removes a whole class of bugs. If the socket drops for ten seconds, or a message is lost, the client refetches over REST and is correct again. Nothing has to be replayed, and a failed publish never fails the upload that caused it.

2. Fan out locally, widen with Redis

We run more than one API replica, and the phone uploading a photo is rarely connected to the same replica as the TV. So every replica fans messages out to its own sockets, and one Redis pub/sub channel widens that across replicas. Each message carries the id of the node that sent it, so a replica drops its own echo.

Redis is only a widener. If it is down, people on the same replica still get live updates, and everyone else catches up on the next refetch.

3. Bounded mailboxes that latch

A projector left running in a corner is the slowest consumer you will ever have. Each socket gets a small bounded mailbox. If it fills up, we do not queue forever and we do not silently drop messages: the backlog is replaced by a single "resync" message, and nothing more is delivered until the client takes it and refetches.

Without the latch, a slow client would apply a stale backlog on top of the fresh copy it just loaded.

4. The wall can only listen

The wall's socket accepts nothing from the client except a keep-alive reply. A screen left running at a venue should not be a second, unaudited way to write into somebody's album.

5. Privacy is checked at both ends

Fondays has a mode called the Dark Room: the album is sealed until a time the host picks, then everything appears at once. A two-metre screen is the loudest possible way to break that promise, so a sealed photo is filtered out where messages are published and again where the wall reads. Either check alone would do. Both together survive the day someone refactors one of them.

6. Re-implement auth carefully

Browsers cannot set headers on a WebSocket, so the socket authenticates differently from the HTTP API. That second implementation is where rules get lost. We wrote down every rule the HTTP path enforces (disabled accounts, permission scoping) and tested the socket path against the same list.

Stack

Flutter for the apps, FastAPI and Postgres (raw SQL, no ORM) for the API, Redis for pub/sub and rate limits, Cloudflare R2 for storage.

If you are hosting something this season, Fondays is free for hosts until June 2027: fondays.com/free

We would like to hear how you handle slow consumers in your own real-time features.

DEV Community: Ondravan