Distributed Persistent Signals: Architecture and Implementation
summary
SignalJ is extended so persistent signals store update histories in a time‑series database and propagate updates via the database itself: each signal instance looks up an ID resolver to get connection info, writes updates into TimescaleDB/Postgres tables with triggers and NOTIFY, and relies on DB‑assigned timestamps for ordering. A merge‑source‑buffer synchronization policy delays joins until all inputs with matching timestamps arrive. Implementation modifies the SignalJ compiler/runtime and adds a DB add‑on; a fan‑controller IoT demo migrates legacy CSV data and works end‑to‑end.
AI-written summary · about
chapters (15)
- 0:00Introduction
- 1:51Reactive programming for IoT
- 3:40Persistent signals and time-series
- 5:05Challenges in distributed signals
- 6:55Location transparency
- 7:39Legacy time-series integration
- 8:48Synchronizing time-series updates
- 10:14Architecture overview
- 13:52Timestamp synchronization policies
- 15:17Key architecture properties
- 17:04Implementation details
- 20:02Fan controller demo
- 20:46Related work
- 21:53Summary and future work
- 22:41Q&A
related talks
26mRealizing Persistent Signals in JavaScript
20mStandardizing Signals in TC39
27m"Write Once Stream Everywhere: Transforming Your Data into Events"
01h 02mReactive Equations
55mReactive Systems: 21st Architecture for 21st Century Systems
29mSecure Database Games
41mProgramming Distributed Systems
44mBuilding a Distributed Queue with Delayed Jobs on PostgreSQL