How Multisynq Synchronization Works
Deterministic Virtual Machine
Multisynq runs your Model code in a deterministic virtual machine called Teatime. This ensures that given the same initial state and the same sequence of events, every user’s device produces exactly the same result.Key Principles
Deterministic Execution
Same inputs always produce same outputs across all clients
Event Ordering
Reflector servers order all events into a single canonical stream
Synchronized Time
Global heartbeat ensures time-dependent operations stay in sync
No Server Logic
Reflectors only pass messages - all logic runs on clients
Architecture Overview
Basic Synchronization Example
Model-Driven State Changes
View Interaction
Advanced Synchronization Patterns
Chat System with Message History
Real-time Cursor Tracking
Synchronized Time and Randomness
Deterministic Time
Deterministic Random Numbers
Future Scheduling
Usefuture()
for time-based events that must stay synchronized:
Best Practices for Synchronization
Do’s ✅
- Use
this.random()
instead ofMath.random()
in Models - Use
this.now()
instead ofDate.now()
in Models - Use
this.future()
for time-based operations in Models - Communicate via events between Model and View
- Keep Models deterministic - no external API calls, random DOM access, etc.
Don’ts ❌
- Never write to Model from View - only through events
- Don’t use
Math.random()
in Model code - Don’t use
Date.now()
orsetTimeout()
in Model code - Don’t access DOM from Model code
- Don’t make HTTP requests from Model code
Connection Resilience
Built-in Reconnection
Multisynq automatically handles:- Temporary network interruptions
- Device sleep/wake cycles
- Browser tab switching
- Connection drops and recovery
View-Level Connection Awareness
Testing Synchronization
Multi-User Testing
Debug Synchronization
- Session connection status
- Messages sent/received
- Event publishing/subscribing
- Heartbeat ticks