The Challenges of Synchronizing Multi-Display Systems

When developing Worship Presenter, the single biggest technical hurdle wasn't the UI or the database—it was Real-Time Synchronization.

The Architecture: Controller vs. Display

Unlike a simple website where every user sees their own state, a presentation tool needs a "Controller" (the operator) and a "Display" (the big screen). When the operator clicks "Next Slide," the display must update instantly, with near-zero latency.

Why Standard HTTP Fails

Traditional request-response cycles are too slow for live performances. Even a 500ms delay in displaying lyrics can throw off an entire band and congregation. We needed a bi-directional, persistent connection.

The Solution: WebSockets (Socket.io)

I chose Socket.io to manage this layer. By maintaining a persistent TCP connection between the server and all clients, we can "push" events from the controller to the display.

socket.on('slideChange', (data) => {
  renderSlide(data.slideId);
});
          

Handling Network Instability

In many church buildings, Wi-Fi can be unstable. We implemented a "State Check" heartbeat. If a display loses connection for even a second, it automatically reconnects and asks the server: "What is the current slide?" This ensures that the display always stays in sync with the operator's intent.

Conclusion

Building real-time systems requires a shift in mindset from "Stateless" to "Stateful." Through Worship Presenter, I've mastered the nuances of event-driven architecture, ensuring that technology serves the moment without getting in the way.