Skip to main content
Understanding the Model-View-Synchronizer (MVS) architecture is fundamental to building successful Multisynq applications. This pattern ensures perfect synchronization across all users while maintaining clean separation of concerns. Multisynq Overview

Core Components

πŸ“± View

Handles user input and output
  • Processes keyboard, mouse, and touch events
  • Determines what’s displayed on screen
  • Interacts with the DOM
  • State is NOT synchronized across users

βš™οΈ Model

Handles calculation and simulation
  • Contains all application logic
  • Manages shared state
  • State is ALWAYS identical for all users
  • Runs deterministic computations

☁️ Synchronizer

Stateless cloud service
  • Routes events between users
  • Mirrors events to all session participants
  • Handles snapshot storage and retrieval
  • Manages session membership

Key Principles

The model state is guaranteed to always be identical for all users.This is the fundamental promise of Multisynq. No matter how many users are in a session, their model state will be perfectly synchronized. This eliminates the complexity of managing distributed state.
// This state is identical across all users
class Game extends Multisynq.Model {
    init() {
        this.score = 0;        // Same for everyone
        this.players = [];     // Same for everyone
        this.gameState = "active"; // Same for everyone
    }
}
View state is NOT synchronized and can differ between users.This allows for personalized experiences while maintaining shared core functionality. Users can have different UI preferences, screen sizes, or device capabilities.
class GameView extends Multisynq.View {
    init() {
        this.darkMode = localStorage.getItem('darkMode'); // User-specific
        this.screenSize = window.innerWidth;              // Device-specific
        this.notifications = [];                          // Local only
    }
}
All communication happens through events.Events provide a clean, decoupled way for components to communicate. The routing is handled automatically by Multisynq.
// View publishes events to model
this.publish("user-input", { action: "move", direction: "left" });

// Model subscribes to events
this.subscribe("user-input", this.handleUserInput);

Session Architecture

1

Session Creation

When a Multisynq application starts, it joins a session. Users with the same session ID will share the same synchronized state.
Multisynq.Session.join({
    name: "my-game-session",
    password: "secret123",
    model: GameModel,
    view: GameView
});
2

Synchronization

The synchronizer ensures all users receive the same events in the same order, maintaining deterministic execution.
3

Snapshot Management

Snapshots are periodically saved to the cloud. New users can join by loading a recent snapshot instead of replaying all events from the beginning.
// Snapshots are handled automatically
// New users join by loading the latest snapshot
// then applying recent events to catch up

Event Routing Rules

Understanding these routing rules is crucial for proper Multisynq development:
  • View β†’ Model
  • Model β†’ View
  • View β†’ View
  • Model β†’ Model
Events from view to model are reflected to all users
// View publishes
this.publish("player-action", { type: "jump" });

// Model receives on ALL devices
this.subscribe("player-action", this.handlePlayerAction);
This ensures all users see the same game state changes.

Data Flow Constraints

Critical Rule: The view can read from the model, but can’t write to it directly.
  • βœ… Correct
  • ❌ Incorrect
class GameView extends Multisynq.View {
    update() {
        // βœ… Reading from model is allowed
        const score = this.model.score;
        const players = this.model.players;
        
        // βœ… Publishing events to model is allowed
        this.publish("user-input", { action: "move" });
        
        // βœ… Updating local view state is allowed
        this.localState.lastUpdate = Date.now();
    }
}

Practical Example

Here’s how the MVS pattern works in practice:
  • Model (Synchronized)
  • View (Local)
class GameModel extends Multisynq.Model {
    init() {
        this.players = new Map();
        this.gameState = "waiting";
        
        // Subscribe to view events
        this.subscribe("player-join", this.addPlayer);
        this.subscribe("player-move", this.movePlayer);
    }
    
    addPlayer(playerData) {
        // This runs on ALL devices
        const player = Player.create(playerData);
        this.players.set(player.id, player);
        
        // Notify views locally
        this.publish("player-added", player);
    }
    
    movePlayer({ playerId, direction }) {
        // This runs on ALL devices
        const player = this.players.get(playerId);
        if (player) {
            player.move(direction);
        }
    }
}

Benefits of MVS Architecture

🎯 Perfect Synchronization

All users see exactly the same state at all times, eliminating sync bugs and conflicts.

πŸ”§ Clean Architecture

Clear separation between business logic (Model) and presentation (View) improves maintainability.

πŸ“ˆ Scalability

Deterministic execution means no server-side state management or complex conflict resolution.

πŸš€ Performance

Local computation with synchronized results provides excellent performance and responsiveness.

Best Practices

  • Keep models deterministic and side-effect free
  • Use future() for time-based behaviors
  • Avoid external dependencies in models
  • Make model state easily serializable
  • Handle all user input in the view
  • Use local state for UI-specific data
  • Avoid blocking operations in the view
  • Keep views responsive and interactive
  • Use clear, descriptive event names
  • Keep event payloads small and simple
  • Avoid high-frequency events when possible
  • Use scoped events for user-specific actions

Common Pitfalls

Avoid these common mistakes:
  1. Direct Model Mutation: Never modify model state directly from the view
  2. Async Operations in Models: Models must be deterministic and synchronous
  3. Heavy View Events: Don’t send large data payloads in events
  4. Circular Dependencies: Avoid event loops between model and view

Next Steps

The Model-View-Synchronizer pattern is the foundation of all Multisynq applications. Understanding this architecture deeply will help you build more robust, maintainable, and scalable multiplayer experiences.
⌘I