Conference Session Booking System

1. Executive Summary

This document outlines the architecture for an event-sourced system using Marten and Redis that handles conference session bookings with waitlists. The architecture supports multiple front-end application servers communicating with single instances of PostgreSQL and Redis servers, focusing on scalability, consistency, and user experience.

2. System Architecture Overview

The system follows a CQRS (Command Query Responsibility Segregation) and Event Sourcing architecture pattern, leveraging:

2.1 Key Components

3. Domain Model

The domain model uses functional programming principles with immutable record types:

// Core domain entities as immutable records
public record Session(Guid Id, string Title, int TotalSeats, DateTimeOffset StartTime);
public record Reservation(Guid Id, Guid SessionId, Guid UserId, DateTimeOffset CreatedAt);
public record WaitlistEntry(Guid Id, Guid SessionId, Guid UserId, int Position, DateTimeOffset JoinedAt);

4. Command Model

Commands represent user intentions and are processed by command handlers:

5. Event Model

Events represent facts that have occurred and are stored in Marten's event store:

6. Projections

Marten projections will maintain read models for efficient querying:

7. Event Sourcing Flow

The system implements a standard event sourcing pattern:

1. Commands are validated
2. Command handlers update aggregates
3. Aggregates emit events
4. Events are stored in the event stream
5. Events are published to event handlers
6. Event handlers update projections and Redis
7. Queries read from projections or Redis

8. Reservation Process Flow

The reservation process implements a single-command approach that handles both successful reservations and waitlist additions:

8.1 Happy Path (Seat Available)

8.2 Sad Path (Session Full)

8.3 Waitlist Promotion

9. Redis Usage Strategy

Redis will be used for:

session:{sessionId}:available → int
session:{sessionId}:total → int

lock:session:{sessionId} → lockToken

waitlist:{sessionId} → {userId: position}

PUBLISH session_update:{sessionId} {JSON data}

10. Implementation Considerations

// Prime Redis cache from projections
foreach (var session in await sessionAvailabilityRepository.GetAllAsync())
{
    await redis.StringSetAsync($"session:{session.Id}:available", session.AvailableSeats);
    await redis.StringSetAsync($"session:{session.Id}:total", session.TotalSeats);
}

// Prime waitlists in Redis
foreach (var waitlist in await waitlistRepository.GetAllAsync())
{
    foreach (var entry in waitlist.Entries)
    {
        await redis.SortedSetAddAsync(
            $"waitlist:{waitlist.SessionId}", 
            entry.UserId.ToString(), 
            entry.Position);
    }
}

var lockKey = $"lock:session:{sessionId}";
var lockToken = Guid.NewGuid().ToString();

if (await redis.LockTakeAsync(lockKey, lockToken, TimeSpan.FromSeconds(10)))
{
    try
    {
        // Process reservation logic
    }
    finally
    {
        await redis.LockReleaseAsync(lockKey, lockToken);
    }
}

11. Technology Stack Summary

12. Conclusion