Session Replay Architecture: How Modern Session Recording Systems Work

Introduction

Session replay technology has become essential for understanding user behavior, debugging issues, and improving product experiences. But how do these systems actually work under the hood? What happens from the moment a user interacts with your website to when you watch their session replay?

This article breaks down the complete architecture of modern session replay services, explaining each component, data flow, and design decision that makes reliable, scalable session recording possible.

High-Level Architecture Overview

Modern session replay systems follow a three-stage architecture pattern:

Architecture Components

Stage 1: Data Collection Pipeline

1. WebPage Integration

The journey begins when a developer integrates a session replay SDK into their web application. This can be done via:

npm install @lognroll/lib

// In your application
import LognRoll from '@lognroll/lib';

LognRoll.initSession('YOUR_APP_ID', {
  // Configuration options
});

<script src="https://logger.lognroll.com/logger.lnr.1.0.1.js"></script>
<script>
  LognRoll.initSession('YOUR_APP_ID', {
    // Configuration options
  });
</script>

2. NPM Module / JS File

The SDK is a lightweight JavaScript module (typically 50-100KB gzipped) that provides:

• Initialization API: Simple methods to start session recording with configuration options
• Configuration Management: Privacy settings, sanitization rules, and feature toggles
• Logger Initialization: Sets up the JavaScript logger that captures user interactions

3. JavaScript Logger

The JavaScript logger is the core data collection engine. It uses browser APIs to capture:

class Logger {
  private domObserver: DOMObserver;
  private networkTracker: NetworkTracker;
  private mouseTracker: MouseTracker;
  private keyboardTracker: KeyboardTracker;

  constructor() {
    // Initialize DOM mutation observer
    this.domObserver = new DOMObserver(this.api);
    
    // Track network requests
    this.networkTracker = new NetworkTracker(this.api);
    
    // Track user interactions
    this.mouseTracker = new MouseTracker(this.api);
    this.keyboardTracker = new KeyboardTracker(this.api);
  }

  // Captures DOM changes
  observeDOM() {
    const observer = new MutationObserver((mutations) => {
      mutations.forEach((mutation) => {
        this.api.sendEvent('DOM_MUTATION', {
          type: mutation.type,
          target: mutation.target,
          // ... sanitized data
        });
      });
    });
    
    observer.observe(document.body, {
      childList: true,
      attributes: true,
      subtree: true
    });
  }
}

4. Web Worker

Web Workers are critical for performance. They run in a separate thread, preventing the main UI thread from being blocked by data processing tasks.

// worker.ts
const chunks: LogEvent[][] = [];

self.onmessage = (event) => {
  if (event.data.type === 'log') {
    const logEvent = event.data.data;
    chunks.push(logEvent);
    
    // Batch events and send when threshold reached
    if (chunks.length >= BATCH_SIZE) {
      sendBatch(chunks.splice(0, BATCH_SIZE));
    }
  }
};

async function sendBatch(batch: LogEvent[]) {
  const logPoints = new proto.LogPoints();
  logPoints.setItemsList(batch);
  const buffer = logPoints.serializeBinary();
  
  await fetch(`${config.baseUrl}/lognroll/${config.companyId}/${config.sid}`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/x-protobuf' },
    body: buffer
  });
}

Stage 2: Data Processing & Storage Pipeline

5. Backend (Encrypting)

When data arrives at the backend, it goes through several critical processing steps:

// Backend encryption service
class EncryptionService {
  async encryptSessionData(sessionData: SessionData): Promise<EncryptedData> {
    // Generate or retrieve session-specific encryption key
    const encryptionKey = await this.getEncryptionKey(sessionData.sessionId);
    
    // Encrypt the session data
    const encrypted = await crypto.encrypt(
      JSON.stringify(sessionData),
      encryptionKey,
      'AES-256-GCM'
    );
    
    return {
      encryptedData: encrypted.ciphertext,
      iv: encrypted.iv,
      tag: encrypted.tag,
      sessionId: sessionData.sessionId
    };
  }
  
  async getEncryptionKey(sessionId: string): Promise<Buffer> {
    // Retrieve or generate encryption key from key management service
    // Keys are stored separately from encrypted data
    return await keyManagementService.getKey(sessionId);
  }
}

6. Message Queue

Message queues are essential for handling high-volume traffic and ensuring data reliability:

{
  "sessionId": "abc123",
  "companyId": "company_xyz",
  "encryptedData": "base64_encoded_encrypted_data",
  "metadata": {
    "timestamp": "2026-01-13T10:30:00Z",
    "eventCount": 150,
    "dataSize": 102400
  },
  "retryCount": 0
}

7. S3 Storage

Cloud object storage (like AWS S3, Google Cloud Storage, or DigitalOcean Spaces) is used for persistent storage:

s3://lognroll-sessions/
  ├── company_xyz/
  │   ├── 2026/
  │   │   ├── 01/
  │   │   │   ├── 13/
  │   │   │   │   ├── session_abc123_encrypted.bin
  │   │   │   │   ├── session_def456_encrypted.bin
  │   │   │   │   └── ...
  │   │   │   └── ...
  │   │   └── ...
  │   └── ...
  └── ...

Stage 3: Playback Pipeline

8. Web Admin (Player)

When a user wants to view a session replay, the process reverses:

9. Backend (Decrypting)

When a playback request is made, the backend:

1. Retrieves the encrypted session data from S3
2. Fetches the decryption key from the key management service
3. Decrypts the session data using AES-256-GCM
4. Applies any additional privacy filters based on user permissions
5. Streams the decrypted data to the player interface

// Backend decryption service
class DecryptionService {
  async getSessionForPlayback(sessionId: string): Promise<SessionData> {
    // 1. Retrieve encrypted data from S3
    const encryptedData = await s3Service.getObject(
      `sessions/${sessionId}/encrypted.bin`
    );
    
    // 2. Get decryption key
    const decryptionKey = await keyManagementService.getKey(sessionId);
    
    // 3. Decrypt the data
    const decrypted = await crypto.decrypt(
      encryptedData.ciphertext,
      decryptionKey,
      encryptedData.iv,
      encryptedData.tag,
      'AES-256-GCM'
    );
    
    // 4. Parse and return session data
    return JSON.parse(decrypted);
  }
}

Data Flow Diagram

Key Design Decisions

Performance Optimizations

Security Considerations

Scalability & Reliability

Conclusion

Modern session replay systems use a sophisticated multi-stage architecture that balances performance, security, and scalability. By leveraging Web Workers for non-blocking processing, encryption for security, message queues for reliability, and cloud storage for scalability, these systems can handle millions of sessions while maintaining low latency and high availability.

Understanding this architecture helps developers make informed decisions when implementing session replay, optimizing performance, and ensuring compliance with privacy regulations.