SaaS and Real-Time Application Architecture

Build the mental model

Modern SaaS (Software as a Service) products extend full-stack architecture with several specialized pieces that show up together often enough to be worth naming as one recognizable shape.

A user's request still travels through DNS and a CDN before reaching the frontend, which talks to a backend API, but the backend itself now branches out to multiple specialized systems.

Authentication to verify who is logged in
A database for the application's core data
Object storage for files like uploads and images
An email service for account confirmations and notifications
External APIs for functionality the product doesn't build itself, like payments or maps

None of these pieces are new concepts introduced here, they are the authentication, database, and API ideas from earlier lessons, just shown working together as a full system.

Real-time application architecture solves a different problem: keeping many users' screens updated live without constant manual refreshing.

The frontend typically maintains two separate channels to the backend at once, a normal HTTP API for regular requests like loading history or saving settings, and a WebSocket connection for live, bidirectional updates like new chat messages arriving instantly.

Behind the backend, a database still stores durable data, but two more pieces usually appear: a cache for data that needs to be read very quickly and repeatedly, and a realtime or event system that decides which connected users need to receive which update the moment something changes.

Neither pattern is more advanced than the other in some absolute sense, they solve different problems, and a single SaaS product often needs both patterns for different features within it.

text

SAAS AND REAL-TIME APPLICATION ARCHITECTURE
-------------------------------------------
SAAS AND REAL-TIME APPLICATION ARCHITECTURE
-----------------------------------------------
MODERN SAAS ARCHITECTURE
  User -> DNS -> CDN -> Frontend -> Backend/API
                                        |
                -------------------------------------
                |        |         |        |       |
              Auth      DB     Storage    Email  External
                                                     APIs

REAL-TIME APPLICATION ARCHITECTURE
  User -> Frontend -- HTTP API ------> Backend
                   \-- WebSocket --->     |
                                          v
                             ------------------------
                             |         |             |
                             DB     Cache    Realtime/Event
                                                System

Connect it to a real scenario

Consider a subscription-based project tracking SaaS product. Most of its screens fit the modern SaaS shape directly: users sign in through the authentication system, their tasks and projects live in the database, uploaded attachments go to object storage, plan renewal reminders go out through the email service, and payment processing is handled by an external API rather than being built from scratch in-house.

One feature stands apart: a live activity feed showing teammates' actions the instant they happen, without anyone refreshing the page.

That feature needs the real-time architecture layered in alongside the SaaS shape, the frontend opens a WebSocket connection specifically for that feed while still using the normal HTTP API for everything else, and the backend's event system decides which currently-connected teammates should receive each new activity update.

This combination is common rather than exceptional: a single product usually is not purely a SaaS-shaped app or purely a real-time app. It layers a WebSocket connection and an event system on top of an otherwise standard SaaS backend for the specific handful of features that genuinely need instant updates, while everything else continues to use the simpler request-response API.

Modern SaaS architecture branches a backend into authentication, database, object storage, email, and external APIs.
Real-time architecture adds a WebSocket channel alongside HTTP, plus a cache and event system for live updates.
These patterns are not competing, a single SaaS product often uses both together for different features.

Try the working example

javascript

function listArchitectureComponents({
  needsRealtimeUpdates,
  needsFileStorage,
  needsEmailNotifications,
  needsThirdPartyAPIs,
}) {
  // Baseline SaaS shape: every SaaS product needs these.
  const components = new Set(["DNS", "CDN", "Frontend", "Backend/API", "Database", "Authentication"]);

  if (needsFileStorage) components.add("Object Storage");
  if (needsEmailNotifications) components.add("Email Service");
  if (needsThirdPartyAPIs) components.add("External APIs");

  if (needsRealtimeUpdates) {
    components.add("WebSocket Connection");
    components.add("Cache");
    components.add("Realtime/Event System");
  }

  return Array.from(components);
}

const product = {
  needsRealtimeUpdates: true,
  needsFileStorage: true,
  needsEmailNotifications: true,
  needsThirdPartyAPIs: false,
};

console.log(listArchitectureComponents(product));

You should see

It prints: [ 'DNS', 'CDN', 'Frontend', 'Backend/API', 'Database', 'Authentication', 'Object Storage', 'Email Service', 'WebSocket Connection', 'Cache', 'Realtime/Event System' ] — the full component list this product needs across both architecture patterns.

5-minute try-it

Take a SaaS product you use (email, project tracking, a note app with sync). List which SaaS components it likely needs, then decide if any feature in it (like live typing indicators or instant sync) needs the real-time architecture layered on top.

One important caution

Adding a WebSocket connection and event system to an entire SaaS product when only one small feature genuinely needs live updates.

Forgetting that a cache and a database serve different purposes in real-time architecture — a cache is not a replacement for durable storage.

Wikipedia — Software as a service — How the Web Works