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

​
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:
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.
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: 
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

​
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

Writing a Multisynq Model

Learn how to build robust, synchronized models

Writing a Multisynq View

Master view development and user interaction

Events & Pub-Sub

Deep dive into event-driven communication

Snapshots

Understand state persistence and recovery
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.