Real-time configuration pipeline
Push-on-save configuration across four services: JSON Schema contracts, a Postgres notify trigger, a FastAPI listener, Redis, and Server-Sent Events to display boards.
Overview
Airport display settings used to live inside the display app and reach screens only after caches expired. I designed the path a saved document now takes, from schema validation through the database to every replica of the FIDS backend and then to the boards.
Problem
A saved display change could take up to about 10 minutes to reach screens (two 5-minute caches). Settings lived in a local database inside the display app.
Role
Designer across four repositories: Configuration Manager, fids-backend, FIDS client, and the admin UI.
Highlights
- JSON Schema contracts for FIDS and translations, plus a cross-repo contract document.
- Transactional PL/pgSQL trigger emits pg_notify('config_changed') with a small key, covering every write path.
- Listener: every replica drops its cache; only one instance re-reads and publishes, so screens are not doubled.
- Publishes only when both documents re-read successfully, so boards never receive a half-updated config.
- Boards apply pushed config over SSE, keep last-known-good, and fall back to a 5-minute poll because Redis pub/sub has no replay.
- Service-account JWT exchange with single-flight caching and failure backoff for the privileged config fetch.
Tech stack
Outcome
Config is pushed on save. Boards keep last-known-good copies when an upstream service is down. Ambiguous tenant-to-airport mappings are refused rather than sent to the wrong screens.