Synchronous vs. Async Projections

Asynchronous projections update after commands complete. The flow is:

1. Command executes and generates events
2. Command returns success to the caller
3. Projections update asynchronously (eventually)

Benefits:

• Performance: Commands return quickly without waiting for projection updates
• Scalability: Projection updates can be batched, queued, or distributed across workers
• Resilience: If projection updates fail, commands still succeed
• Decoupling: Write and read models evolve independently

Drawbacks:

• Stale data: Users might see outdated information immediately after actions
• Complex UI: Requires loading states, polling, or optimistic updates
• Race conditions: Users might act on stale data before projections update

Synchronous projections update before the command returns. The flow is:

1. Command executes and generates events
2. Projections update immediately
3. Command returns success with updated projection data

Benefits:

• Consistency: Users always see up-to-date data immediately
• Simplicity: No need for loading states or optimistic updates
• Correctness: Prevents actions based on stale data
• Better UX: Immediate feedback feels more responsive

Drawbacks:

• Performance: Commands take longer, blocking until projections update
• Scalability: Harder to scale projection updates independently
• Tight coupling: Write and read models must be updated together
• Failure modes: If projection updates fail, the entire command might fail

Use asynchronous projections for:

• Background jobs and batch processing
• Analytics and reporting (can tolerate slight delays)
• High-throughput systems where performance is critical
• Operations where eventual consistency is acceptable

Use synchronous projections for:

• GUI operations where users need immediate feedback
• Actions that depend on up-to-date projection data
• Workflows where correctness is more important than performance
• Operations where stale data could cause user confusion

In the State-Based Collaboration Framework, projections are by default asynchronous for command execution. This provides the performance and scalability benefits mentioned above. However, the framework also supports synchronous projection generation for GUI operations.

The key insight is that GUIs need synchronous action and projection generation to ensure correct operation. When a user triggers an action through the GUI, they expect to see the result immediately. If projections update asynchronously, the UI might show stale data, leading to confusion or incorrect subsequent actions.

Importantly, synchronous projections are not configured by action but are provided by the GUI at runtime. When a GUI triggers an action, it specifies which projections it needs updated synchronously based on what it's currently displaying. This makes the system flexible and allows different GUIs to request different projections for the same action, depending on their context.

GUIs have unique requirements that make synchronous projections necessary:

The framework supports both modes:

Synchronous projections are not configured by action but are provided by the GUI at runtime. When a GUI triggers an action, it provides a list of projections it expects to be updated synchronously. The GUI knows which projections it needs because it queries those projections to show data to the user.

This runtime approach means:

• The same action can be called with different projection lists depending on the GUI context
• Different GUIs can request different projections for the same action
• The GUI explicitly declares its dependencies at the point of action execution
• No static configuration is needed—the system adapts to what each GUI needs

The framework flow:

• GUI identifies needed projections: The GUI queries projections to display data to the user. It knows which projections it depends on.
• Action request includes projection list: When triggering an action, the GUI includes a list of projections it expects to be updated synchronously.
• Action executes: The action executes and generates events (as normal).
• Synchronous projection updates: The framework immediately computes and updates only the projections specified in the request, synchronously.
• Returns updated data: The action returns success with the updated projection data for the specified projections.
• GUI displays immediately: The GUI can display the updated data immediately, ensuring correctness.

This approach is efficient because:

• Only the projections the GUI actually needs are updated synchronously
• Other projections can still update asynchronously, maintaining performance
• The GUI explicitly declares its dependencies, making the system self-documenting
• No unnecessary synchronous work is performed

Consider a document submission workflow:

If this were asynchronous, the user might see the document still in "Draft" state for a moment, causing confusion or leading them to try submitting again.