How I Built a Snapchat Clone Using Claude Code: Glint

Glint is a camera-first messaging app. It covers the product category Snapchat made popular, but it uses its own name, palette and data. I built it from a single 390×844 design file. That file shows the Chat inbox: a yellow-ringed profile avatar, search, an "Add friends" button and an overflow menu, the filter chips All / Unread / Groups / Stories, eight chat rows with coloured status squares, a blue pencil FAB and a five-tab bottom bar with a yellow camera button in the middle. The palette comes straight from the design tokens: camera yellow #FFFC00, chat blue #0EADFF, Snap red #F23C57 and video-Snap purple #A05DCD, with Inter for type.

The inbox matches the design pixel for pixel. Everything else is built from the same visual language: the chat thread, the full-screen Snap viewer, the camera with lenses, the Send To sheet, Stories with a Discover section, the Spotlight short-video feed, the friend map and the profile sheet. The streak column was an emoji in the design. Here it is an inline SVG flame next to the day count, because the brief bans emoji as icons.

What is real

• Every control works. Filter chips filter. Search hits both local chats and a server people-search endpoint. Add friends sends a request that is accepted a few seconds later. The FAB creates 1:1 or group chats through POST /api/chats. The More menu marks everything read, clears conversations and resets the demo.
• The status state machine is the core of this product and it is implemented end to end. A text you send shows Delivered (blue outline), then Opened when the simulated friend reads it, then the friend starts typing, then a reply arrives as New Chat (filled blue) or Received if you are looking at the thread. A Snap you send shows Delivered in red, flips to Opened a few seconds later, and sometimes a Snap comes back, which extends the streak.
• Ephemerality. Each chat has a delete policy: after viewing (messages both sides have seen disappear when you leave the thread) or 24 hours after viewing (a timer purges them). Press and hold to save a message, exactly like the real thing. Received Snaps open in a full-screen viewer with a countdown ring, are marked opened the moment they are shown, and cannot be replayed.
• The camera is live. getUserMedia with front/back flip, a flash (screen flash for the front camera, torch constraint for the rear one where the hardware supports it) and nine lenses. Each lens is a CSS filter plus an optional gradient overlay applied live to the <video>, and the same filter is replayed on a canvas at capture time with ctx.filter. You can caption, set a 3/5/10 second view time, download, send to friends or groups, or post to My Story. If permission is denied it falls back to a sample photo or an upload.
• Real video. Stories → Discover and Spotlight use the 15 shorts and the long-form episodes from Suhas Bhairav's channel (The Bhairav Show). Thumbnails come first, and only the active item mounts a youtube-nocookie.com iframe. Every player links back to YouTube.

What is simulated

The other people are simulated. The provider schedules client timers that walk each conversation through opened → typing → reply, and the reply text comes from a small rule-based picker behind POST /api/chat/reply. Server writes go to in-memory module state. The browser keeps the source of truth in localStorage, so the demo survives restarts. Media never leaves the browser: POST /api/snaps records only the fan-out metadata and TTL. There is no encryption. The rest of this guide is about what it takes to replace each of those simulations with a production system that holds up for millions of people. That means end-to-end encryption, guaranteed deletion of ephemeral media, a receipt state machine you can trust, and a realtime tier that keeps millions of sockets open.

Glint was built with Claude at every step. I designed it with Claude on a design canvas in Claude, coded and tested it with Claude Code, and used Claude Opus 5.5 to work out how it scales to millions of users. Here is the actual workflow, including what I decided and what Claude did.

Stage	Claude tool	What it did
Design	Claude design canvas	The app screens were designed with Claude on a design canvas, one board per product.
Coding	Claude Code	A Claude Code sub-agent wrote Glint: 41 files, 6 pages, 10 API routes, in about 31 minutes.
Parallel agents	Claude Code sub-agents	Six clones were built at the same time, one sub-agent per app.
Testing & screenshots	Claude Code	Build, lint, a running server and 10 screenshots that Claude reviewed and fixed.
Scalability & infrastructure analysis	Claude Opus 5.5	Capacity math, Hetzner server plans, real-time design, security and cost models.

1. Design with Claude

I designed the screens with Claude on a design canvas: six app screens, one board per product, each in the palette of the product it is modelled on. The Glint design uses an original name and original copy, so the clone borrows the product category and layout conventions, not Snapchat's brand.

2. One shared brief, written with Claude Code

Before any app code, Claude Code wrote one brief that all six builds followed. It read the design boards from the Claude canvas, pulled my channel's videos from YouTube, and fetched current prices from Hetzner. The brief covered:

• Stack: the existing create-next-app scaffold (Next.js 16, React 19, Tailwind CSS v4). Next 16 has breaking changes, so Claude was told to read the docs bundled in node_modules/next/dist/docs/ rather than rely on memory.
• Fidelity: match the design's layout, hex colours, fonts and spacing; replace grey placeholders with real media; use stroke SVG icons, not emoji.
• "Fully working": every visible control must do something, backed by Next.js route handlers so the UI talks to an API like a real product.
• Media: real videos from @suhasbhairav played through privacy-enhanced embeds.
• Proof: build, run, screenshot every main flow, look at each screenshot, fix what's wrong.

3. Coding with Claude Code sub-agents, in parallel

The main Claude Code session started six sub-agents, one per clone, each owning one folder and one port, so the six apps were built at the same time. Every agent ran on Claude Opus 5.5. The Glint agent worked for about 31 minutes. In that run Claude:

1. Read the design file and the Next.js 16 docs it needed.
2. Wrote the app: 41 source files, about 3,748 lines, with 6 page routes and 10 API route handlers (/api/bootstrap, /api/chat/reply, /api/chats, /api/chats/[id]/messages, /api/friends, /api/map, /api/search, /api/snaps, /api/spotlight, /api/stories).
3. Ran npm run build and npm run lint until both passed cleanly.
4. Started the production server and drove headless Chrome to capture 10 screenshots. For true phone-width shots it wrote a small Chrome DevTools Protocol script, because Chrome's --window-size flag won't lay out narrower than about 500px.
5. Opened every screenshot, fixed the bugs it saw, and re-shot.

4. Analysing scalability with Claude

The sections that follow, from the data model to the cost breakdown, were drafted with Claude Opus 5.5. That covers capacity math, the Postgres and caching plan, Hetzner server choices per growth stage, the real-time notification design, security and monthly costs. Each one is marked where it starts. Claude worked from Hetzner's own price pages, fetched that day, rather than from memory, and showed its arithmetic so the estimates can be checked.

5. Review: Claude checking Claude

The main Claude Code session reviewed each agent's output instead of trusting it. It looked at the screenshots and rendered every page. It also caught an inconsistency across the six write-ups: some cost tables listed the price of one server where others listed the row total. All tables were normalised to show both. The agents were explicit about which parts are simulated (in-memory server state, fake payments or uploads where relevant) and which paths were not tested, and this page keeps that explicit.

What this means if you want to do the same

• Spend your time on the brief, not the boilerplate. A precise brief (stack, fidelity bar, definition of "working", proof required) is what made six parallel Claude Code builds come back consistent.
• Make Claude prove it. "Build passes, here are screenshots I looked at" is a much stronger signal than "done".
• Keep the architecture decisions yours. Claude wrote the code and the first draft of the scaling plan; deciding what is real, what is simulated and what goes to production is still the engineer's job.
• Start here: Claude Code overview · Sub-agents · Claude Opus

Page routes in the clone

/ · /camera · /chat/[id] · /map · /spotlight · /stories

Every screen below is a real route or query-string state, so each one can be bookmarked and screenshotted. All shots are 390×844 except the last.

1. Chat inbox

This is the design, reproduced. Row weight follows status: unread rows (New Snap, New Chat, purple video Snap) are bold, the rest are regular. The status square uses the design's radius rules: 2px corners for Snaps, 3px for chats, filled when new and outlined once handled. Friends with a story get a gradient ring around their avatar, and tapping the avatar opens their story instead of the chat. The Unread chip shows a live count, and the Chat tab carries the same number as a badge. Tapping a row with a pending Snap opens the viewer directly (/?snap=priya). Any other row opens the thread.

2. Chat thread with typing indicator

Messages are grouped by sender with coloured name labels and a left rule: red for you, blue for the friend, and a distinct colour per member in groups. Day separators read Yesterday · 10:00 AM and Today · 10:20 AM. Saved messages have a grey background and a bookmark. Here I just sent "hey! still on for saturday?". It shows Opened, Priya is typing (header and inline dots), and a reply lands about two seconds later. The clock button switches the chat between delete after viewing and 24 hours after viewing.

3. Snap viewer

The countdown ring drains over the Snap's duration (6 seconds here). Hold to pause, tap to skip. The Snap is marked opened as soon as it renders, because that is the moment the sender should see Opened. The viewer snapshots its items on mount, so marking them opened does not pull them out from under the playback.

4. Camera with lenses

This is Chrome's fake media device (the green test pattern) with the Dream lens on. The right rail has flip, flash and upload from camera roll. The lens carousel sits above the shutter, and the shutter takes on the selected lens's swatch. Capturing draws the frame into a 540×960 canvas with cover-crop maths. The front camera is mirrored, the lens filter and overlay are applied, and the result is a JPEG data URL.

5. Send To

Recipients are sorted by streak, then groups, then friends you have never chatted with (a chat is created for them on send). Opening the camera from a thread (/camera?to=priya) preselects that person. The blue bar lists the selection. Sending calls POST /api/snaps, which returns one delivery receipt per chat, and each row flips to Delivered.

6. Stories and Discover

The friends row puts unseen stories first. Subscriptions holds long-form episodes of The Bhairav Show. Discover is a 9:16 grid of the channel's shorts: the hqdefault thumbnail with object-fit: cover crops the letterboxing so only the vertical frame shows. Tapping one opens a full-screen player (/stories?discover=<id>) with prev/next and Watch on YouTube. The story viewer (/stories?story=hana) has segmented progress bars and a reply box that sends a chat.

7. Spotlight

A CSS scroll-snap feed (snap-y snap-mandatory). An IntersectionObserver at 60% visibility decides which card is active. Only that card mounts the iframe, and it is oversized so YouTube's own chrome is cropped. A transparent layer above the iframe keeps vertical swipes working and turns double-tap into a like. Pages load with a cursor from /api/spotlight.

8. Friend map

An SVG city (river, parks, block grid, arterial roads) with avatars placed from /api/map. Drag to pan, wheel or buttons to zoom, and recenter on yourself. Selecting a friend (/map?friend=priya) shows their place and last-seen time with Chat and Snap actions. The ghost button opens a Ghost Mode switch that replaces your avatar with a ghost and stops the pulsing location ring.

9. Profile and streaks

The profile sheet (top-left avatar, ?sheet=profile) has an editable display name, username, a score, counters, a streak list and settings: Ghost Mode, notifications, and the default delete policy for new chats.

10. Desktop

On viewports at least 640px wide and 860px tall, the app renders inside a 390×844 device frame on a neutral backdrop. On a phone it fills the screen with 100dvh.

Glint uses the Next.js 16 App Router with React 19 and Tailwind CSS v4, in plain JavaScript. cacheComponents and partialPrefetching are enabled, which matters in two places.

1. Every screen that reads useSearchParams sits inside <Suspense>. Under Cache Components, search params are request-time data, so the static shell is a spinner and the client fills it in.
2. The thread route awaits params inside a Suspense boundary. app/chat/[id]/page.js renders <Suspense><ThreadRoute params={params}/></Suspense>, and ThreadRoute awaits the promise. That makes /chat/[id] a partial prerender: a static shell with a streamed hole.

Routes

Route	Screen	URL state
/	Inbox	?filter=unread|groups|stories, ?sheet=search|add|more|new|profile, ?snap=<chatId>
/chat/[id]	Thread	?snap=<messageId>
/camera	Camera	?lens=<id>, ?to=<chatId>, ?sample=1, ?auto=1
/stories	Stories / Discover	?story=<friendId|me>, ?discover=<videoId>
/spotlight	Feed	?i=<index>
/map	Map	?friend=<id>

Sheets and viewers are query-string states, not separate routes, so they layer over the current screen and the back button closes them. All state changes use router.replace(..., { scroll: false }) so the inbox keeps its scroll position.

State: one provider, pure updates

components/GlintProvider.js is the client store. It is a useReducer with a single generic action, fn: (state) => newState, plus small pure helpers (patchChat, pushMsg, mapMsgs, bump). Actions are memoised once and close over a stateRef, so timers never read stale state. The provider:

• loads from localStorage (glint:v1) and falls back to GET /api/bootstrap. The seed stores "minutes ago" and the server converts that to absolute timestamps, so the inbox always reads 2m, 9m, 24m like the design.
• persists with a 250 ms debounce. If the quota is exceeded (captured JPEGs are big) it trims My Story and retries.
• purges 24-hour chats every minute and applies the delete after viewing rule when a thread unmounts. That cleanup is deferred by 80 ms and skipped if the same chat remounts, so React StrictMode's double-mount in development does not wipe a conversation.
• simulates the other side. simulateReply(chatId, text, kind) chains timers: mark my messages seen, set typing, call POST /api/chat/reply, append the reply, and set the status to chat, received (if the thread is open) or snap. It also updates the streak when a Snap comes back on a day I snapped.

The thread tells the provider which chat is on screen through setActiveChat. That ref decides whether an incoming reply counts as read immediately.

Components

components/
  GlintProvider.js   store, persistence, simulation, toasts
  ui.js              Avatar, StatusSquare, Streak, BottomNav, Sheet, Toggle, Splash, ytThumb/ytEmbed
  icons.js           ~40 inline stroke icons incl. FlameIcon
  inbox/             Inbox, AddFriendsSheet, NewChatSheet, MoreMenu, SearchOverlay, ProfileSheet
  Thread.js          thread + LongPress save + delete-mode menu
  SnapViewer.js      countdown viewer shared by inbox and thread
  camera/            Camera (getUserMedia, lenses, capture, caption) + SendToSheet
  stories/           Stories (friends, subscriptions, discover, player) + StoryViewer
  Spotlight.js       scroll-snap feed with IntersectionObserver
  MapScreen.js       SVG map, pan/zoom, ghost mode
lib/
  seed.js status.js lenses.js replies.js server-store.js format.js

lib/status.js is a direct port of the design's renderVals() table (label, colour, fill, radius, weight per status). Inbox rows, thread receipts and the viewer all render from that one table, so a status always looks the same everywhere.

Data fetching

Seed data, search, friends, chats, messages, replies, snaps, stories, Spotlight pages and map positions all go through route handlers. Under Cache Components a GET handler is prerendered unless it touches request data, so the handlers whose responses change call await connection() or read request.nextUrl. Mutations are POST with JSON bodies. The message endpoint is idempotent on a client-generated clientId, the same contract a production send path needs.

Media handling in the browser

There are no image libraries. Avatars are colour swatches from the design with initials. Story and Snap photos are picsum.photos seeds. YouTube thumbnails come from i.ytimg.com. Using plain <img> avoids next/image remote-pattern configuration in a demo. A production build would serve its own media through next/image or a CDN image resizer.

The production model splits into two stores. PostgreSQL holds identity, the social graph, conversation metadata, ciphertext envelopes and receipts. Object storage holds encrypted media blobs. The server never stores plaintext message bodies or media keys. A row in message is an opaque ciphertext plus routing metadata, and one row exists per recipient device. That is how Signal-style fan-out works: the sender encrypts once per device session.

Core schema

CREATE TABLE app_user (
  id            bigint PRIMARY KEY,               -- snowflake: time-ordered, shard-friendly
  username      citext UNIQUE NOT NULL,
  display_name  text NOT NULL,
  created_at    timestamptz NOT NULL DEFAULT now(),
  ghost_mode    boolean NOT NULL DEFAULT false,
  deleted_at    timestamptz
);

CREATE TABLE device (
  id              bigint PRIMARY KEY,
  user_id         bigint NOT NULL REFERENCES app_user(id),
  identity_key    bytea NOT NULL,                 -- Curve25519 public identity key
  signed_prekey   bytea NOT NULL,
  spk_signature   bytea NOT NULL,
  pq_prekey       bytea,                          -- Kyber/ML-KEM last-resort key (PQXDH)
  push_token      text,
  push_kind       text CHECK (push_kind IN ('apns','fcm','webpush')),
  last_seen_at    timestamptz,
  revoked_at      timestamptz
);
CREATE INDEX ON device (user_id) WHERE revoked_at IS NULL;

CREATE TABLE one_time_prekey (                    -- consumed exactly once
  device_id  bigint NOT NULL REFERENCES device(id),
  key_id     int    NOT NULL,
  public_key bytea  NOT NULL,
  PRIMARY KEY (device_id, key_id)
);

CREATE TABLE friendship (
  user_id    bigint NOT NULL,
  friend_id  bigint NOT NULL,
  state      text   NOT NULL CHECK (state IN ('requested','accepted','blocked')),
  created_at timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (user_id, friend_id)
);

CREATE TABLE conversation (
  id            bigint PRIMARY KEY,
  kind          text NOT NULL CHECK (kind IN ('direct','group')),
  title_enc     bytea,                            -- group name is E2EE metadata too
  mls_group_id  bytea,                            -- for MLS groups
  delete_policy text NOT NULL DEFAULT 'after_view' CHECK (delete_policy IN ('after_view','24h')),
  last_seq      bigint NOT NULL DEFAULT 0,        -- per-conversation sequence counter
  created_at    timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE conversation_member (
  conversation_id bigint NOT NULL,
  user_id         bigint NOT NULL,
  joined_seq      bigint NOT NULL,
  read_seq        bigint NOT NULL DEFAULT 0,
  streak_count    int    NOT NULL DEFAULT 0,      -- denormalised for the inbox (direct only)
  streak_expires  timestamptz,
  PRIMARY KEY (conversation_id, user_id)
);
CREATE INDEX ON conversation_member (user_id);

-- One envelope per recipient device. Partitioned by day; dropped wholesale after TTL.
CREATE TABLE message (
  conversation_id bigint      NOT NULL,
  seq             bigint      NOT NULL,
  recipient_dev   bigint      NOT NULL,
  sender_dev      bigint      NOT NULL,
  kind            smallint    NOT NULL,           -- 1 text, 2 snap, 3 video snap, 4 receipt, 5 control
  ciphertext      bytea       NOT NULL,
  media_id        uuid,                            -- object key for snaps (encrypted blob)
  client_id       uuid        NOT NULL,            -- idempotency key from the sender
  created_at      timestamptz NOT NULL DEFAULT now(),
  expires_at      timestamptz NOT NULL,
  PRIMARY KEY (recipient_dev, conversation_id, seq, created_at)
) PARTITION BY RANGE (created_at);
CREATE UNIQUE INDEX ON message (sender_dev, client_id, created_at);

CREATE TABLE receipt (
  conversation_id bigint NOT NULL,
  seq             bigint NOT NULL,
  user_id         bigint NOT NULL,
  state           smallint NOT NULL,              -- 1 sent 2 delivered 3 opened 4 screenshot 5 replayed
  at              timestamptz NOT NULL DEFAULT now(),
  PRIMARY KEY (conversation_id, seq, user_id, state)
);

CREATE TABLE media_object (
  id            uuid PRIMARY KEY,
  bucket        text NOT NULL,
  bytes         int  NOT NULL,
  remaining     smallint NOT NULL,                -- recipients that have not opened yet
  expires_at    timestamptz NOT NULL,             -- 30 days unopened, 24h for stories
  deleted_at    timestamptz
);
CREATE INDEX ON media_object (expires_at) WHERE deleted_at IS NULL;

Why it is shaped like this

• Envelopes are short-lived queue entries, not history. A message row exists until every recipient device has acknowledged it. After that the client owns the plaintext and applies the chat's delete policy locally. The server deletes the row on acknowledgement and partitions by day as a backstop: DROP TABLE message_p2026_11_04 removes a whole day of expired ciphertext in milliseconds, with no vacuum debt. That is the main reason for range partitioning on created_at.
• Per-conversation seq. UPDATE conversation SET last_seq = last_seq + 1 ... RETURNING last_seq hands out a gap-free order inside a conversation. Clients detect gaps and request a resync. Global ordering is never needed.
• Receipts are their own table, keyed by state. A receipt is append-only (delivered never turns back into sent) and screenshot or replay events are rare extras. The inbox status is derived from the newest receipt and cached in Valkey per (user, conversation).
• Streaks are denormalised onto conversation_member with an expiry timestamp. A job looks for streaks expiring in the next 4 hours to send the hourglass warning.

Sharding

Shard by conversation_id for conversation, conversation_member, receipt and the sender side of message, so one conversation's sequence counter and receipts live on one shard. The recipient read path ("give me everything pending for device D") is served by a per-device inbox queue in NATS JetStream or Valkey Streams and does not scatter across shards. Postgres stays the durable record, and the realtime tier reads from the queue. Users and devices shard by user_id. Snowflake IDs carry a shard number in their low bits, so the router never needs a lookup table. Start with one primary and Citus or application-level routing in mind. You need the second shard well before 5M MAU because of write volume, not data size: message rows are tiny and short-lived.

The production API is REST over HTTPS for request/response work, plus one WebSocket per device for everything pushed. All endpoints are versioned (/v1), authenticated with a short-lived access token bound to a device, and return application/json (or application/x-protobuf for mobile clients that opt in).

Method	Path	Purpose	Notes
POST	/v1/devices	Register a device with identity key, signed prekey and 100 one-time prekeys	Returns device_id
GET	/v1/users/{id}/prekey-bundle	Fetch a bundle for each of a user's devices to start a session	Consumes one OTPK per device atomically
POST	/v1/devices/me/prekeys	Top up one-time prekeys	Client refills below 20
GET	/v1/conversations?cursor=	Inbox: conversations ordered by last activity	Cursor = (last_activity, id)
POST	/v1/conversations	Create direct or group chat	Idempotent on client_id
POST	/v1/conversations/{id}/messages	Send one envelope per recipient device	Body is a batch, server assigns seq
GET	/v1/conversations/{id}/messages?after_seq=	Gap fill after reconnect	Returns only envelopes for the caller's device
POST	/v1/media/uploads	Get a presigned PUT URL for an encrypted blob	Size and content-length enforced
POST	/v1/receipts	Batch receipts {conv, seq, state}	Coalesced, max 100 per call
GET	/v1/stories/feed?cursor=	Friends' stories and Discover	Discover cached at the CDN
POST	/v1/location	Update shared location	Throttled, dropped in ghost mode
GET	/v1/friends/suggestions	Quick Add	Rate limited

Cursor pagination

Never use offsets. The inbox cursor is an opaque base64 of (last_activity_at, conversation_id), and the query is WHERE (last_activity_at, id) < ($1, $2) ORDER BY last_activity_at DESC, id DESC LIMIT 30 on a matching composite index. Message gap fill uses after_seq, which is already monotonic per conversation. In the clone, /api/chats/[id]/messages?before= and /api/spotlight?cursor= follow the same pattern.

Idempotency

Mobile networks retry. Every mutation carries a client-generated UUID: client_id on messages and conversations, and the Idempotency-Key header everywhere else. The send path relies on UNIQUE (sender_dev, client_id). On conflict it returns the original seq with 200 instead of creating a duplicate, so a retried Snap never shows up twice. The clone's POST /api/chats/[id]/messages already deduplicates on clientId. Store idempotency results for 24 hours in Valkey for endpoints that have no natural unique key.

Rate limits

A token bucket in Valkey per (user, action), enforced at the edge and the API:

Action	Limit (starting point)
Messages sent	60 / minute, 2,000 / day
Snaps sent	30 / minute, 600 / day, max 200 recipients per send
Friend requests	20 / hour, 100 / day
Prekey bundle fetches	300 / hour (stops key-exhaustion attacks)
Location updates	1 / 15 s while foregrounded
Search	30 / minute

Return 429 with Retry-After. New accounts get tighter buckets for their first week. That one rule removes most spam.

WebSocket protocol

One socket per device, multiplexed with small framed messages:

→ {"t":"hello","dev":123,"resume":{"conv:42":118,"conv:77":9}}
← {"t":"msg","conv":42,"seq":119,"env":"<base64 ciphertext>","kind":2}
→ {"t":"ack","conv":42,"seq":119}
← {"t":"rcpt","conv":42,"seq":117,"user":88,"state":"opened"}
→ {"t":"typing","conv":42,"on":true}
← {"t":"presence","user":88,"state":"active"}

hello carries the last acknowledged seq per conversation, so the gateway replays only what is missing. ack lets the server delete the envelope. Everything is binary (Protocol Buffers) on mobile. The JSON above is for readability.

Capacity model and architecture drafted with Claude Opus 5.5 inside Claude Code. All figures are estimates with the arithmetic shown.

All numbers in this section are estimates for planning. They are not measurements of the clone. Change the per-user assumptions to match your own telemetry once you have it.

Assumptions (Scale tier, ~5M MAU)

Input	Value	Reasoning
MAU	5,000,000	tier target
DAU	2,500,000	50% DAU/MAU: camera-chat apps are habit products
Chat messages sent / DAU / day	40
Snaps sent / DAU / day	20
Average recipients per Snap	1.5	most Snaps go 1:1, some to small groups
Average encrypted Snap size	~0.33 MB	85% photos at ~120 KB + 15% video at ~1.5 MB → 0.85×0.12 + 0.15×1.5 = 0.327 MB
Peak-to-average ratio	3×	evening peaks
Peak concurrent sockets	20% of DAU	foreground plus recently backgrounded

Derived load

• Message writes: 2.5M × 40 = 100M/day → 100,000,000 / 86,400 ≈ 1,160/s average, ~3,500/s peak. Each send to a 1:1 chat with two devices on the other side writes 2 envelope rows plus 1 sender-sync row, so plan for ~10,000 row inserts/s at peak. That is comfortable for a well-tuned Postgres on NVMe with batched inserts, but it is the reason to plan a second shard before this tier.
• Snap sends: 2.5M × 20 = 50M/day → ~580/s average, ~1,750/s peak.
• Media ingress: 50M × 0.33 MB ≈ 16.5 TB/day uploaded.
• Media egress: 16.5 TB × 1.5 recipients ≈ 24.75 TB/day, which is about 742 TB/month. As bandwidth: 24.75 TB / 86,400 s ≈ 286 MB/s ≈ 2.3 Gbit/s average, ~7 Gbit/s peak.
• Media at rest: most Snaps are opened within hours and deleted on open. If the average lifetime is about 2 days with a long tail of unopened Snaps (30-day TTL), steady state is roughly 16.5 TB × 2 ≈ 33–40 TB stored. Retention, not ingest, drives storage cost, which is why aggressive deletion pays off twice.
• Receipts: every message and Snap produces delivered and opened receipts → ~(100M + 75M) × 2 ≈ 350M receipts/day, about 4,000/s on average. Receipts are coalesced (one opened up to seq N replaces N individual events), which cuts this by 5–10×.
• Concurrent sockets: 20% × 2.5M = 500,000 at peak.
• Typing and presence events: ephemeral and never persisted. If 5% of sockets are typing at any moment with an update every 3 s, that is ~8,000 events/s fanned out to 1–30 recipients each.

Architecture (request path, top to bottom)

1. DNS + CDN/WAF (Cloudflare or Bunny) for the web app, static assets and the Discover/Spotlight thumbnails. Encrypted Snap blobs bypass the CDN cache: each one is read once or twice, so caching buys nothing.
2. Hetzner Load Balancers (or HAProxy pairs with keepalived on dedicated servers) split into two pools: api. for REST and ws. for WebSockets, with long idle timeouts.
3. Stateless API tier (Node.js or Go) that handles auth, prekey bundles, sends, presigned uploads and receipts. Scale it horizontally on CPU.
4. WebSocket gateway tier, stateful only in the sense that it holds sockets. It knows nothing about business logic. It subscribes to the per-device subjects of its connected devices on the backplane.
5. NATS JetStream as the backplane and per-device durable inbox: subject dev.<id> with a work-queue stream, a max age of 30 days and acknowledge-to-delete. Kafka works too, but it is heavier to run yourself at this size.
6. Valkey cluster for sessions, rate limits, presence (SET presence:<user> EX 60), typing, idempotency keys and inbox status caches.
7. PostgreSQL: a primary plus a synchronous standby per shard, async read replicas for inbox and friend reads, PgBouncer in transaction mode in front (thousands of API connections become ~200 server connections), and daily partitions for message and receipt.
8. Object storage (S3 API) for encrypted media, with lifecycle expiry rules. Uploads and downloads go straight from devices with presigned URLs, so the API never proxies bytes.
9. Workers consuming JetStream: push notifications (APNs/FCM), streak expiry, media garbage collection, abuse-report processing, story fan-out.

Stateless app tier

API pods hold no session state. Tokens are verified locally with JWKS, and anything mutable lives in Valkey or Postgres. That lets you autoscale on CPU and do rolling deploys without draining. The gateway is the exception: draining a gateway means sending every socket a reconnect frame with jittered backoff (spread over 30–60 s) so the remaining nodes do not get a thundering herd.

Caching

Cache derived data, never ciphertext. That means the inbox list (inbox:<user>, a sorted set of conversation ids by last activity), per-conversation status for the viewer, friend lists, prekey bundle counts, and Discover pages at the CDN edge. Invalidate on write through the same NATS events the gateways consume. One event bus feeds both realtime and cache invalidation.

Multi-region

Start in one region (Falkenstein/Nuremberg) with backups in Helsinki. Messaging tolerates a little latency, but sockets do not like long round trips. Past ~5M MAU, put gateway-only edges near users (Ashburn, Hillsboro, Singapore) that terminate TLS and WebSockets locally and forward over a private backbone to the home region. Later, give each user a home region and route conversations to the region of their creator. Cross-region conversations then cost one extra hop for some participants, which is fine at messaging timescales. Media buckets live in the uploader's region. Recipients download cross-region, and that is still cheaper than replicating every blob.

Server plan drafted with Claude from Hetzner's own price pages, fetched by Claude Code on 11 November 2026. Verify prices on hetzner.com before ordering.

Hetzner is a good fit for messaging because the workload is many sockets, steady CPU, NVMe Postgres and lots of egress, and Hetzner's traffic pricing and dedicated AX boxes are very cheap for exactly that. Prices below are excl. VAT, as listed on hetzner.com in Nov 2026. Verify before ordering. Some shared Cloud plans show as "currently not available" in certain locations, so have a fallback plan size ready.

Honest limits first

• Regions: Germany (Falkenstein, Nuremberg), Finland (Helsinki), USA (Ashburn VA, Hillsboro OR) and Singapore. Dedicated AX servers are in DE/FI only. There is nothing in South America, Africa or India, so put a CDN (Cloudflare or Bunny) in front for global latency on static assets, and add gateway edges where you need them.
• No managed PostgreSQL. You run it yourself (Patroni + pgBackRest) or buy it from a provider that runs on Hetzner. This guide assumes self-managed.
• Cloud traffic: EU cloud servers include 20 TB/month. US cloud plans include only 1–5 TB, so US gateway edges should not serve media.
• Object Storage is S3-compatible and cheap (€6.49/month including 1 TB storage and 1 TB egress, then ~€6.35/TB-month storage and ~€1/TB egress, with free ingress, internal traffic and API calls). Benchmark request rates per bucket before relying on it for tens of TB/day, and spread keys across several buckets by hash prefix.
• DDoS protection is automatic on every product. That covers volumetric attacks. You still need a WAF and application rate limits.

Stage 1, Launch (0–50K MAU): Docker Compose + Ansible

Two CPX32 (4 vCPU/8 GB) behind an LB11 run the Next.js app, the API and the WebSocket gateway as Compose services. Two more CPX32 run PostgreSQL 17 primary and streaming replica on local NVMe. One CPX22 runs Valkey and a single NATS server with JetStream. Everything sits in a Cloud Network (10.0.0.0/16). Only the load balancer is public. The Cloud Firewall allows 443 to the LB and 22 from a bastion or Tailscale. Ansible playbooks provision users, Docker, node_exporter and the Compose stacks. pgBackRest pushes WAL continuously and a full backup nightly to an Object Storage bucket in a different location.

Stage 2, Growth (~500K MAU): k3s on Cloud

Move to k3s with three control-plane CPX22 nodes (cheap etcd quorum) and worker pools. API pods run on CPX42 workers, gateways on dedicated-vCPU CCX23 (16 GB, so socket memory is predictable), and media and push workers on CPX42. Postgres moves to two CCX33 (8 dedicated vCPU/32 GB) managed by Patroni, with PgBouncer as a sidecar Deployment. NATS becomes a 3-node JetStream cluster. Use Hetzner Volumes only for things that can tolerate network block storage (NATS file store at this size, Prometheus). Keep Postgres on local NVMe. The hcloud cloud-controller-manager provisions LBs from Kubernetes Services, and the CSI driver handles Volumes.

Stage 3, Scale (~5M MAU): dedicated AX + k3s/Kubernetes

Cloud shared vCPU gets expensive and noisy once you are pushing gigabits of WebSocket traffic, so this is the stage to move to dedicated AX servers. An AX42 (Ryzen 7 PRO 8700GE, 8 cores, 64 GB ECC, from €79) handles about 150K idle WebSockets with room to spare. AX102 (16 cores, 128 GB, 2×1.92 TB NVMe DC, from €159) runs the Postgres shards. Link the servers with a vSwitch (VLAN) to your Cloud Network so cloud LBs and burst capacity can reach them. Order the 10 Gbit uplink add-on for gateway and media-heavy boxes, because the default 1 Gbit/s port saturates at the media peaks above. Kubernetes keeps running (k3s, or kubeadm with Cilium) across both the AX nodes and cloud nodes for bursty workers.

Stage 4, Hyperscale (10M+ MAU)

Run two DE/FI sites (Falkenstein + Helsinki) with Postgres shards spread so each primary's synchronous standby is in the other site, plus gateway edges in Ashburn and Singapore on cloud instances. Keep separate clusters per site rather than one stretched cluster, and federate them with NATS super-clusters (gateways between clusters) so a device connected in Helsinki gets messages published in Falkenstein.

When to move from cloud to dedicated

Move once a role needs more than ~3 CCX33-equivalents running continuously. A CCX33 is €138.99/month (NBG1) for 8 dedicated vCPU and 32 GB. An AX102 is €159 for 16 cores, 128 GB and 3.8 TB NVMe. Setup fees (€49–€304) pay for themselves within the first month. Keep cloud for anything that autoscales, anything short-lived, and US/Singapore edges.

Backups and drills

• pgBackRest: continuous WAL archiving plus a weekly full and daily differential to Object Storage in another location, encrypted with a repo key. Target RPO under 1 minute, RTO under 1 hour per shard.
• NATS: JetStream replicas=3 is your durability. It is not backed up, because envelopes are transient by design.
• Do not back up media. Ephemeral media that survives in a backup is a privacy bug. Your lifecycle rules must cover every copy.
• Run a restore drill monthly: restore the latest backup into a scratch server, replay WAL to a point in time and run consistency checks.

Real-time design and code drafted with Claude Opus 5.5 in Claude Code.

Realtime is the product. The inbox only feels alive if Delivered → Opened → typing… → New Chat happens within a few hundred milliseconds, which in the clone is a chain of client timers. In production it is a persistent connection per device.

Transport choice

• WebSockets are the default: bidirectional, supported everywhere, cheap on the server with the right runtime. Mobile apps keep one socket while foregrounded.
• SSE handles server-to-client only. It is fine for a web inbox, but typing and receipts go upstream constantly, so you would still need POSTs. Skip it.
• WebTransport (HTTP/3) avoids head-of-line blocking and survives network changes better. It is worth adding later for clients on bad networks, but WebSocket remains the baseline because of proxy and corporate-network compatibility.
• Mobile background: the OS kills sockets. Delivery to backgrounded devices goes through APNs/FCM. Web clients use Web Push with VAPID.

Gateway sizing (estimates)

A WebSocket gateway is a memory-and-file-descriptor problem before it is a CPU problem. With uWebSockets.js or a Go gateway (gorilla/gws or nbio), plan on 10–20 KB per idle connection including TLS state and subscription bookkeeping. 150,000 connections × 20 KB ≈ 3 GB, so an AX42 with 64 GB has huge headroom for memory. The real limits are TLS handshakes during reconnect storms and the outbound fan-out rate. I plan around ~150K connections per AX42-class box, which leaves enough CPU to absorb a reconnect storm.

• Scale tier: 500,000 peak sockets / 150,000 ≈ 3.3 → 6 gateways (N+2 for deploys and zone loss).
• Hyperscale: ~1.2M peak sockets / 150,000 = 8 → 14 gateways across two sites.

Kernel tuning: raise fs.nr_open and ulimit -n to 1M, set net.core.somaxconn=65535, widen net.ipv4.ip_local_port_range on the LB side, and enable TCP keepalive at 60 s. Send app-level pings every 25 s, because carrier NATs drop idle flows around 30–60 s.

Off-the-shelf or custom?

Centrifugo (Go, MIT) gives you channels, presence, history, recovery with offsets, JWT auth and a NATS/Redis broker out of the box. It is a strong choice up to millions of connections. Soketi is Pusher-compatible but lighter on recovery semantics. For a messaging product with per-device queues and E2EE envelopes, a custom gateway of a few hundred lines on uWebSockets.js is often simpler, because the gateway only has to do four things: authenticate, subscribe to dev.<id>, forward frames and relay acks.

Backplane and fan-out

Use fan-out on write for messages: the sender already produced one envelope per recipient device, so the API publishes each to dev.<recipientDevice> on NATS JetStream (a durable work-queue stream). Whichever gateway holds that device's socket has a consumer on that subject and pushes immediately. If the device is offline, the message waits in the stream (that is the offline queue) and a push notification goes out. Typing and presence are ephemeral: they go over core NATS subjects (conv.<id>.typing) with no persistence. Gateways subscribe per conversation only for sockets that have that conversation open on screen, which keeps typing fan-out small.

Location sharing is different. Each update fans out to N friends, but only to friends currently looking at the map. Publish to loc.<user>. Map screens subscribe to the subjects of friends in view and unsubscribe when the map closes. Throttle updates to every 15–30 s while foregrounded and never send location in background unless the user chose live location.

Ordering and delivery guarantees

• Order per conversation, not globally. The server assigns seq in the conversation's shard. Clients render by seq and buffer out-of-order frames briefly.
• At-least-once delivery plus idempotent clients. JetStream redelivers until the device acks. The client deduplicates on (conv, seq). The sender's client_id deduplicates retries on the send side. Together they give effectively-once in the UI.
• Gap detection. If a client sees seq 120 after 118, it calls GET /messages?after_seq=118 instead of waiting.
• Reconnect with resume. hello carries the last acked seq per active conversation (the last-event-id idea, per conversation). Reconnect backoff is exponential with full jitter: sleep = random(0, min(30s, 0.5s × 2^attempt)).

Backpressure

Each socket has a bounded send buffer, for example 256 KB. When getBufferedAmount() crosses it, the gateway stops pulling from that device's consumer (JetStream max-ack-pending does the rest). Typing and presence frames are dropped first, because they are ephemeral and only the latest matters. If the buffer stays full for 30 s, close the socket with code 1013 and let the client resume. Never let one slow phone on a train hold memory for everyone.

Push notifications

A push worker consumes a push.* stream. It is triggered when the API publishes an envelope to a device whose presence key in Valkey is absent or older than 60 s. For APNs use token-based auth (.p8 key) over HTTP/2 with apns-push-type: alert, mutable-content: 1 (so a Notification Service Extension can decrypt a preview on device), apns-collapse-id per conversation and apns-expiration matching the message TTL. For FCM use the HTTP v1 API with data-only high-priority messages (the app decrypts and builds the notification) and a collapse_key per conversation. For Web Push, VAPID with an encrypted payload and a TTL header. The payload never contains plaintext: it is the encrypted envelope or just "you have something" plus the conversation id. Respect the user's notification toggle (the clone's profile setting) on the server side as well.

Typing indicators and presence

Typing is client-throttled: send typing:on at most every 3 s while keys are pressed and typing:off on send or blur. Gateways expire a typing state after 5 s without refresh, so a crashed client never leaves a stuck "typing…". Presence is a Valkey key with a 60 s TTL refreshed by socket pings. "Active now" is computed on read, not broadcast to every friend on every change.

Deep-dive drafted with Claude Opus 5.5 in Claude Code.

This is the system that makes a camera-chat product hard. Users are promised two things that pull against each other: messages arrive instantly on every device, and messages are gone afterwards. Both have to be true at the same time, without the server being able to read anything.

1. End-to-end encryption

1:1 chats: the Signal protocol. Each device publishes an identity key, a signed prekey and a stack of one-time prekeys (plus a post-quantum ML-KEM prekey for PQXDH). To start a session, the sender fetches a prekey bundle per recipient device, runs X3DH/PQXDH to derive a shared secret, and then uses the Double Ratchet. Every message advances a symmetric chain (forward secrecy), and every reply round trip mixes in a fresh Diffie-Hellman (post-compromise security). The server only stores public keys and relays ciphertext. Use libsignal (Rust, with Swift/Java/TypeScript bindings). Do not write your own ratchet.

Groups: MLS (RFC 9420). Pairwise Signal sessions in a group cost O(n) encryptions per message, and adding or removing members gets messy. MLS uses a ratchet tree, so adding or removing a member costs O(log n) and every member derives the same epoch secret. One ciphertext per message goes to the whole group. OpenMLS (Rust) is production-grade. The delivery service (your server) orders commits per group. That ordering requirement is exactly the per-conversation seq from the data model. Under ~10 members, Signal "sender keys" are a simpler stopgap, but MLS is where the industry is going.

Multi-device. Treat each device as its own cryptographic identity. A user's devices form a device list, and a sender encrypts to every device of every recipient, plus their own other devices so sent messages sync. New devices are linked by scanning a QR code on an existing device, which transfers the account identity key over an ephemeral channel. History does not transfer by default, which suits an ephemeral product. Key changes surface as a "safety number changed" notice. Add key transparency (an append-only, auditable log of identity keys, in the style of CONIKS or the key-transparency logs WhatsApp and Apple published) once you are big enough to be a target.

What the server still sees is metadata: who talks to whom and when, sizes and IP addresses. Minimise it. Use sealed sender (the sender's identity goes inside the ciphertext, and delivery is authorised with an anonymous delivery token), short log retention, and padded media sizes in fixed buckets.

2. Ephemeral media with per-object keys

The device compresses first (§5), then generates a random 256-bit media key per Snap and encrypts the blob with AES-256-GCM (or ChaCha20-Poly1305 on low-end Android). It uploads the ciphertext to object storage through a presigned PUT to a random UUID key. The media key, digest and object id travel inside the E2EE message. The server stores bytes it cannot decrypt and holds no key that could decrypt them.

Crypto-shredding makes deletion real: once every recipient device's copy of the media key is gone, the ciphertext is noise, wherever it was copied. Devices delete the key when the Snap is opened (and keep a separate local copy only for "replay once"). The server's job is to delete the ciphertext promptly as a second line of defence.

3. TTL and guaranteed deletion

Run three layers of deletion, and assume each one can fail on its own:

1. On open: a recipient's opened receipt decrements media_object.remaining. At zero, a worker issues DELETE on the object within seconds.
2. Lifecycle rules: every media bucket has an S3 lifecycle expiration (for example, prefix snaps/ expires after 31 days and stories/ after 2 days), so even if the database and workers are both broken, the storage itself enforces the maximum TTL. Lifecycle rules run on day granularity, which is why they are the backstop and not the main mechanism.
3. Sweeper: an hourly job scans media_object WHERE expires_at < now() AND deleted_at IS NULL, deletes the objects and marks the rows. It also catches orphans: uploads whose message was never sent.

Make deletion observable. Export media_objects_overdue_total (rows past expires_at and not yet deleted) and alert if it is ever non-zero for more than an hour. Never back up media buckets, keep media out of CDN caches (Cache-Control: no-store on presigned GETs), and keep access logs for days, not months. Message envelopes in Postgres follow the same pattern: delete on ack, with daily partitions dropped after the max TTL.

4. Delivery receipts as a state machine

           upload ok          gateway push/ack       viewer shown        OS screenshot hook
 [sending] ────────▶ [sent] ───────────────▶ [delivered] ──────────▶ [opened] ──▶ [screenshotted]
     │                                                                   │
     └──── fail after retries ──▶ [failed]                               └──▶ [replayed] (once)

States only move forward. Receipts are themselves E2EE control messages (kind 4), so the server never learns that a Snap was opened, only that a small envelope went back. The sender's client folds the receipts it receives into the inbox status: Delivered (filled red or outline blue), Opened, Screenshot. That is exactly what lib/status.js renders in the clone. Coalesce receipts ("opened up to seq N") and batch them every ~500 ms to cut traffic by an order of magnitude. Screenshot detection is best-effort: iOS exposes userDidTakeScreenshotNotification after the fact, Android 14+ has a screenshot-detected callback, and the web has nothing. Present it honestly as a deterrent, not a guarantee.

5. On-device capture, compression and upload

• Photos: capture at the preview resolution, apply lenses on the GPU (Metal/Vulkan shaders, or WebGL in the browser; the clone uses Canvas 2D ctx.filter), then encode HEIC/AVIF on capable devices or JPEG at quality ~0.8. That lands around 80–200 KB at 1080p.
• Video: H.264 (or HEVC where supported) with hardware encoders at 720p/1080p, ~2–3 Mbit/s, 10 s max per segment, AAC audio. Longer captures are chunked into multiple Snaps.
• Upload: start uploading while the user is still typing a caption or picking recipients. Encrypt and upload speculatively to a temporary key and commit on send. That one trick makes sending feel instant. Use resumable or multipart uploads for video, retry with exponential backoff, and keep a persistent outbox so a Snap sent in a tunnel goes out when the network comes back.
• Strip metadata: remove EXIF and GPS before encryption unless the user explicitly attaches a location.

6. Streak computation

A streak counts consecutive days on which both people sent each other at least one Snap (chats do not count). Store per pair: streak_count, last_day_a, last_day_b and expires_at. On each Snap send from A to B, evaluated in UTC or in the pair's agreed timezone:

1. Set last_day_a = today.
2. If last_day_b == today and the streak has not been incremented today, increment it and set expires_at = end_of(tomorrow).
3. A job looks for pairs with expires_at - now() < 4h and sends the "hourglass" warning push.
4. Another job resets streaks past expires_at to 0.

Because Snap contents are E2EE, the server must not infer streaks from content. It uses envelope metadata (kind = Snap) that it already sees for routing. Be transparent with users that this metadata exists. The clone keeps the same rule in miniature: iSnappedDay plus a Snap coming back on the same day increments the streak once.

7. Location sharing privacy

Location is the most sensitive data in the app, so build it so that it is opt-in, coarse by default and short-lived:

• Ghost Mode (the clone's toggle) means the client stops sending updates and the server deletes the last location. It is not just a flag that hides it at read time.
• Audience: all friends, selected friends, or "all friends except". Evaluate the audience at fan-out time, not when the map renders.
• Precision: snap to a ~100 m grid for most audiences. Precise location only for an explicit "share live location for 1 hour" session.
• E2EE location: encrypt location updates per friend (the same Signal sessions) so the server routes only ciphertext. Heatmaps and public "Snap Map" style features then need a separate, explicitly public, aggregated pipeline.
• Retention: keep only the last location with a TTL of 8–24 h (a Valkey key with EX). Never keep a history unless the user turns on a feature that needs one.
• Never update location in the background without OS-level "always" permission and a visible indicator.

Threat model and mitigations drafted with Claude in Claude Code.

Authentication and sessions

• Sign-in: phone number or email with OTP for account recovery, passkeys (WebAuthn) as the primary factor, and OIDC (Sign in with Apple/Google) as an option. Rate-limit OTP sends per number and per IP, and use a CAPTCHA or Play Integrity / App Attest signal before sending SMS. SMS pumping fraud is a real cost line.
• Sessions: a short-lived access token (JWT, 10–15 min, signed with rotating keys published as JWKS) bound to a device_id, plus an opaque refresh token stored hashed in Postgres and rotated on every use, with reuse detection that revokes the device. Web uses an HttpOnly; Secure; SameSite=Lax cookie instead of storing tokens in JS. Sessions here are per device anyway, so revocation is "delete the device row and close its socket".
• Authorisation: every conversation operation checks membership (conversation_member), and media GETs need a presigned URL that the API issues only to members. Object keys are random UUIDs, never sequential.

OWASP Top 10, specific to this app

Risk	Where it bites a camera-chat app	Mitigation
Broken access control	Fetching someone else's prekeys, messages or media by id	Membership checks on every query, presigned URLs with 5-minute expiry, no listable buckets
Cryptographic failures	Home-grown crypto, nonce reuse in media encryption	libsignal/OpenMLS, random 96-bit GCM nonces with a fresh key per object, TLS 1.3 only
Injection	Search, usernames	Parameterised queries, citext usernames with a strict charset
Insecure design	Server-side "delete" that leaves backups	Crypto-shredding and lifecycle rules as described above
Security misconfiguration	Public bucket, debug endpoints	Infra as code, CI policy checks, separate buckets per data class
Vulnerable components	Image decoders (libwebp-class bugs)	Decode only on device, keep deps patched, Renovate + SCA in CI
Auth failures	OTP brute force, SIM swap	Attempt limits, passkeys, registration lock PIN
Integrity failures	Malicious app updates or lens packages	Signed builds, signed lens bundles
Logging failures	No trail for account takeover	Audit log below
SSRF	Link previews	Generate previews on the sender's device, never on the server

Headers and CSP (web)

Content-Security-Policy: default-src 'self'; img-src 'self' blob: data: https://i.ytimg.com https://*.your-cdn.com; media-src 'self' blob:; frame-src https://www.youtube-nocookie.com; connect-src 'self' wss://ws.example.com https://*.your-object-storage.com; script-src 'self' 'nonce-…'; frame-ancestors 'none', plus Strict-Transport-Security: max-age=63072000; includeSubDomains; preload, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy: camera=(self), microphone=(self), geolocation=(self).

Abuse, spam and moderation under E2EE

The server cannot read content, so moderation has to rely on: user reports (the reporter's client decrypts and attaches the reported messages, a "message franking" scheme proves they really were sent), metadata signals (account age, send velocity, friend-request acceptance rate, many recipients who never reply), on-device classifiers that warn recipients ("this may be sensitive, view anyway?"), and legally required CSAM handling where your jurisdiction mandates it, designed with counsel. Public surfaces (Spotlight, public stories, Discover) are not E2EE, so they go through a server-side pipeline: malware scanning on upload, perceptual hashing against known-abuse hash lists, ML classifiers and a human review queue.

Secrets, encryption and network

• Secrets live in SOPS-encrypted files (age keys) or Vault. They never go in images or env files in git. Kubernetes uses External Secrets.
• TLS 1.3 at the edge, mTLS or WireGuard between nodes over the private network (vSwitch/Cloud Network), LUKS full-disk encryption on dedicated servers, and pgBackRest repo encryption.
• DDoS: Hetzner's automatic network-level protection, a CDN/WAF in front of HTTP, connection-rate limits on the WebSocket LB, and per-IP connection caps on gateways.

GDPR and India's DPDP Act

Collect the minimum. Publish retention periods (they are short by design, so say so). Support data export (profile, friends, saved chats on request from the client, because the server does not have plaintext) and full account deletion within 30 days, including devices, prekeys, friend edges and any media. Sign DPAs with processors (Hetzner, push providers, SMS vendor). Get explicit consent for location sharing. Record a lawful basis for each processing purpose. Keep EU data in EU regions. Under DPDP, appoint a grievance officer and handle children's data with verifiable parental consent.

Audit logging

Write an append-only security log of sign-ins, device links and revocations, key changes, password or passkey changes, data exports, admin actions and moderation decisions. Ship it to a separate Loki tenant or object store with write-once retention for 1 year. Never put message content or media keys in any log.

Telemetry stack

• Metrics: Prometheus (or VictoriaMetrics once cardinality grows) scraping node_exporter, postgres_exporter, PgBouncer, NATS (/varz, JetStream), Valkey and app metrics through OpenTelemetry SDKs. Grafana dashboards per tier.
• Logs: structured JSON to Loki through Grafana Alloy. Log ids and states, never content.
• Traces: OpenTelemetry → Tempo. Trace the send path end to end: API POST /messages → Postgres insert → NATS publish → gateway push → client ack. The trace id travels in NATS headers.

The metrics that matter for this product

Metric	Why
send_to_deliver_ms p50/p95/p99	Time from API accept to recipient gateway push. SLO: p95 < 300 ms within a region
deliver_to_ack_ms	Client health and network quality
ws_connections per gateway, ws_connect_rate	Capacity and reconnect storms
jetstream_pending per consumer group	Offline queue growth, stuck consumers
push_sent_total, push_failures_total{reason}	APNs/FCM token churn, quota problems
media_upload_fail_ratio, upload p95	Client and network issues
media_objects_overdue_total	Deletion guarantee. SLO: zero objects more than 1 h past TTL
Postgres replication lag, PgBouncer wait queue	Database health

SLOs and alerting

• Message delivery availability: 99.95% of sends accepted and pushed or queued within 5 s, per 30 days.
• Inbox load: p95 < 400 ms.
• Ephemeral deletion: 100% of media deleted by TTL + 1 h. This is treated as a privacy SLO, and missing it pages someone.

Alert on burn rate (multi-window, multi-burn-rate as in the Google SRE workbook), not on raw thresholds. Page only on user-visible impact or a privacy SLO breach. Send everything else to a ticket queue. Run a weekly on-call rotation with runbooks linked from every alert: gateway drain, Patroni failover, JetStream stream repair, APNs certificate or key expiry.

Load testing

Use k6 with the WebSocket module for socket soak tests. Ramp to 1.5× expected peak connections, hold for an hour, and measure memory per connection and GC pauses. Simulate reconnect storms by killing a gateway under load. Run k6 HTTP scenarios for the send path at 3× peak write rate against a production-sized staging database. For media, upload synthetic 120 KB and 1.5 MB blobs at peak rate to verify object storage throughput per bucket.

Chaos and recovery drills

Monthly: kill a Postgres primary (Patroni should promote within ~30 s), kill a NATS node, drain a gateway during peak, and restore a pgBackRest backup to a point in time. Quarterly: a regional failover game day. Record time to detect and time to recover.

CI/CD

GitHub Actions or Forgejo: lint, unit tests, Playwright end-to-end tests against an ephemeral environment (the clone's URL-addressable states make these easy to write), container build with SBOM and signing (cosign), then deploy through Argo CD with progressive rollout: canary 5% of API pods, then 50%, then all, with automatic rollback on SLO burn. Database migrations are expand/contract and backwards compatible for one release. Gateway deploys drain gradually, a few percent of sockets per minute.

Cost model calculated by Claude Code from the Hetzner line items above, excl. VAT.

These are monthly running costs for the four infrastructure tiers in the tables on this page. They use Hetzner list prices, excl. VAT, as listed on hetzner.com in Nov 2026. Verify before ordering. Cost per 1K users is computed at the top of each tier's MAU range, so it is the best case for that tier. All traffic and storage figures are estimates derived in the scaling section.

Tier	Users	Infra / month	Per 1K MAU	of which Object Storage
Launch	0–50K MAU	€176.44	€3.53	€6.49
Growth	~500K MAU	€1,079.39	€2.16	€98.54
Scale	~5M MAU	€3,389.14	€0.68	€995.14
Hyperscale	10M+ MAU	€9,284.10	€0.93	€2,007.14

Not included: one-time setup fees for AX servers (€49–€304 each), 10 Gbit uplink add-ons, a CDN/WAF plan (Cloudflare or Bunny), SMS for OTP (often the largest variable cost in a phone-number-first app: budget per verification and fight SMS pumping), Apple/Google developer accounts, and people. APNs and FCM are free.

Main cost drivers

1. Media egress and retention. At the Scale tier, Object Storage is about a third of the bill, and nearly all of that is egress (742 TB × ~€1/TB). Hetzner's egress pricing is what makes this affordable at all. The same traffic on a hyperscaler at typical list prices of several cents per GB would cost tens of thousands of euros a month.
2. Database write volume. Envelope rows and receipts, not storage. Sharding comes from write IOPS and WAL volume.
3. Sockets. Gateways are cheap per box but scale linearly with concurrent users.
4. SMS verification, if you lead with phone numbers.

How to cut them

• Compress on device harder. Moving photos from JPEG to AVIF/HEIC at the same visual quality typically saves 30–50% of bytes, and egress falls with it.
• Delete on open, aggressively. Every hour a blob sticks around after its last open is wasted storage. Lifecycle rules are the backstop, not the plan.
• Coalesce receipts and typing. Batch receipts every ~500 ms and send typing at most every 3 s. That removes most small writes and frames.
• Use dedicated AX servers early for steady loads (gateways, Postgres, NATS). One AX102 at €159 replaces several cloud instances.
• Keep media out of the CDN. Ephemeral blobs have near-zero cache hit rates, and paying CDN egress on top of origin egress is waste. Use the CDN for the app shell, thumbnails and public Discover/Spotlight only.
• Passkeys first, SMS second. Every sign-in that skips SMS saves money and removes an attack surface.

Phase 1: foundations (weeks 1–4)

• Replace the localStorage store with a real backend: Postgres schema from this guide, migrations, snowflake ids.
• Accounts: phone/email OTP + passkeys, device registry, refresh-token rotation.
• Device keys and prekey bundles with libsignal. Encrypt text messages end to end.
• WebSocket gateway + NATS JetStream per-device inbox. Replace the clone's reply timers with real delivery and E2EE receipts.
• Turn /api/chats/[id]/messages into the batched per-device envelope endpoint with client_id idempotency.

Phase 2: ephemeral media (weeks 5–8)

• Presigned upload/download to Hetzner Object Storage, per-object AES-GCM keys, speculative upload during caption entry.
• Deletion triple: delete on last open, lifecycle rules, hourly sweeper, plus the media_objects_overdue_total alert.
• Native camera apps (Swift/Kotlin) with GPU lenses. Keep the web camera from the clone for desktop.
• Stories with 24 h TTL. Replay-once and screenshot receipts.

Phase 3: groups, push and safety (weeks 9–12)

• MLS groups with OpenMLS. Group admin and membership commits ordered per conversation.
• APNs/FCM/Web Push workers with encrypted payloads and collapse keys.
• Rate limits, new-account throttles, reporting with message franking, moderation tools for public surfaces.
• Streak service and hourglass notifications.

Phase 4: launch readiness (weeks 13–16)

• Location sharing with Ghost Mode, coarse default precision and E2EE updates.
• Observability stack, SLOs, runbooks, on-call.
• k6 soak at 1.5× target sockets, chaos drills, restore drill.
• Privacy policy, DPA, GDPR/DPDP export and deletion flows, external security review and E2EE protocol audit.
• Staged rollout: closed beta → one country → general availability, with the Hetzner tier sized one step ahead of demand.