Scaling to 1,000 concurrent customers

What breaks, what doesn't, and the order in which we fix things. Written for the team — direct, with the honest numbers.

1What 1,000 customers actually means

Numbers first, so nobody argues with adjectives. Rough, honest estimates:

2What already scales — and why

One building, many rooms

A customer link has two parts. Everything before the first slash is the building (a domain — registered once, never touched again). Everything after it is the room (a token — one database row, created automatically per customer):

The system, as it runs today

flowchart LR
  C["Customer
(token link, no login)"] --> D["portal.omni1.ch / .de
(planned, 2 A-records)
seo.omni-dashboards.com (today)"]
  T["Team"] --> H["Hub + internal tools
seo.omni-dashboards.com only"]
  D --> N["nginx
one VPS"]
  H --> N
  N --> F["Next.js SSR
(portal, forms)"]
  N --> A["FastAPI
(one API)"]
  F --> A
  A --> P[("Supabase / Postgres
production since Aug 14")]
  A --> G["Google Search Console API
per-customer property"]
  W["Windmill
(automation layer)"] --> CL["Close CRM"]
  W --> DS["DocuSeal"]
  W --> A
  classDef hot fill:#1b1416,stroke:#DF1B21,color:#f2f0ee
  classDef cool fill:#151517,stroke:#2a2a2e,color:#f2f0ee
  classDef db fill:#12181a,stroke:#1fa971,color:#f2f0ee
  class C,D hot
  class N,F,A,H,T,W,CL,DS cool
  class P,G db

Already settled and scale-proof: Postgres in production (cutover Aug 14, SQLite kept only as dev copy and rollback point), token-based portals (customer = row, not infrastructure), Windmill as the automation layer, and the two-domain plan (dom-948).

3The four workstreams

3.1 Finish hardening Postgres — don't replace it

The migration is done; the hardening is not. The dangerous part is invisible today: when data moves from SQLite to Postgres the naive way, UNIQUE, FOREIGN KEY, DEFAULT and NOT NULL constraints are silently lost — they live inside SQLite's CREATE TABLE text, not in the schema views a migration script reads. We have documented this exact failure before. With one customer nobody notices. At 300, missing indexes mean slow queries, and missing constraints mean silent data corruption.

• Audit every table: indexes, FKs, UNIQUE, NOT NULL — against the old SQLite DDL.
• Connection pooling (Supabase pooler) before concurrent portal traffic grows.
• A Postgres-native backup concept — the old per-deploy SQLite snapshot is meaningless now.

3.2 Precompute portal payloads

Today every portal visit may trigger a live build: Search Console queries plus report computation, cached 300 s per project. Fine for ten customers, hostile at a thousand — especially on a 2-vCPU VPS shared with the asset library.

flowchart TD
  subgraph today ["Today — compute on request"]
    V1["Visitor opens portal"] --> M1{"cache fresh?"}
    M1 -->|no| B1["GSC queries + compute
seconds, on the web server"]
    M1 -->|yes| R1["render"]
    B1 --> R1
  end
  subgraph target ["Target — compute on schedule"]
    W2["Worker refreshes every project
on a fixed cycle, off-peak aware"] --> S2[("precomputed read model
one indexed row per project")]
    V2["Visitor opens portal"] --> S2
    S2 --> R2["render in milliseconds"]
  end
  classDef hot fill:#1b1416,stroke:#DF1B21,color:#f2f0ee
  classDef cool fill:#151517,stroke:#2a2a2e,color:#f2f0ee
  classDef db fill:#12181a,stroke:#1fa971,color:#f2f0ee
  class V1,B1,M1 hot
  class R1,V2,W2,R2 cool
  class S2 db

Alongside: resize the VPS (a click) or move workers off the web box, and manage GSC API quotas per property — the one external ceiling we don't control.

3.3 Marginal cost per customer → zero

This is the real scaling project. Every step below is charming at ten customers and a full-time job at a thousand:

Rule of thumb for every new feature from now on: “Does this work for 1,000 customers without a human touching each one?”

3.4 Hardening that only matters at mass

• Rate-limit the public portal endpoint (tokens are unguessable; the load isn't).
• Monitoring on portal.omni1.* — the customer domain joins the heartbeat.
• Separate TLS certificates per domain, so one renewal failure can't touch both.
• One base-URL config — three places in the code still hardcode the old domain (offer_engine ×2, writing/map_endpoint ×1). Every stamped link goes through one function.
• Shared DNS zone discipline: omni1.ch/.de zones are also touched by website work. The portal records must be documented and monitored — deleting two lines there would take down every customer link at once.

4The road, in thresholds

5What we deliberately do not change

• No microservices, no Kubernetes, no rewrite. One app, one API, one database is a feature at this size.
• No per-customer infrastructure. No subdomains, no containers, no DNS per customer — ever.
• No login for portal customers. Token links stay; adding accounts would add cost at exactly the wrong place.
• No second system per market. Two domains are two names on one door; behavior follows data, not host.

6The honest limit

Past these thresholds the bottleneck stops being machines. “Personal support” is a promised deliverable in the offer, and content delivery — however productized — has human review in the loop. The machine roadmap above buys the room for that conversation; it doesn't replace it.