Problem class: API-driven display systems—displays whose content and behaviour are controlled by code and data from APIs or databases, not by manual uploads or creative schedules alone. Systems involved: Source-of-truth (API, database, queue engine, property management), integration layer, display application. Why non-trivial: Data must propagate correctly; update behaviour (push vs pull, event vs scheduled) must match requirements; display must not become an alternate source-of-truth. If done incorrectly: Display shows wrong or stale data; drift from source; silent failure. This page explains programmatic control, source-of-truth driven content, push vs pull and event-driven vs scheduled updates.
Programmatic Control of Displays
Programmatic control means that what is shown is determined by code and data, not by manual uploads or creative schedules alone. The display application fetches data (e.g. room status, queue position, production count), applies logic (formatting, filtering, conditional visibility), and renders the result. Changes to the source data propagate to the display according to defined rules: polling interval, event-driven push, or hybrid. The key is that the display is a consumer of a data pipeline, not a standalone content store.
Programmatic control enables correctness: the display reflects the current state of the source system. It also enables consistency: many displays can consume the same source and show the same (or context-appropriate) information. We design display systems around this model: define the source-of-truth, define the transformation logic, and define the update behaviour.
Source-of-Truth Driven Content
Source-of-truth driven content means that the authoritative data lives in one place (or a well-defined set of places): a database, an API, a queue engine, a property management system. The display does not hold the truth; it reflects it. When the source changes, the display updates (subject to update rules). When the source is unavailable, the display behaves in a defined way: show cached data with staleness, show fallback content, or show an error state. We do not allow the display to become an alternate source-of-truth; that leads to drift and inconsistency.
Event-Based vs Scheduled Updates
Updates can be event-based (push: the source notifies the display when data changes) or scheduled (pull: the display polls the source at intervals). Event-based updates reduce latency and unnecessary polling but require a push mechanism (webhooks, message queue, or long-lived connection) and robust handling of missed or out-of-order events. Scheduled updates are simpler to implement and debug but may introduce delay and unnecessary load when data changes infrequently. We choose the update model based on requirements: how fresh must the data be? How often does it change? What infrastructure is available?
Observability
Operational displays need observability: monitoring, alerting, and logs so that failures are detected and can be acted on. We design for visibility: health checks, staleness indicators, and integration with monitoring platforms where appropriate. The goal is that when something goes wrong, someone knows.
Why this matters in real deployments
Displays that drift from the source-of-truth or fail silently can cause operational errors. Programmatic control, defined update behaviour, and observability make systems correct and maintainable.