StackPrism
Data and IoT

Tech stack for a product analytics platform (2026)

Event analytics for websites, designed by StackPrism from one sentence: 14 components, a reason for each, and the live checks that watch them.

The stack

  • Next.js
  • Google Cloud Pub/Sub
  • Clerk
  • Stripe
  • Redis
  • Google Cloud Storage
  • PostgreSQL
  • ClickHouse
  • Sentry
AnalyticsBig dataGoogle CloudUpdated
The idea someone typed
“A product analytics tool: a JavaScript snippet sends page views and custom events from our customers’ websites, and they explore funnels, retention and live visitors in a dashboard. Expect billions of events a month.”

Their answers on the constraints step

Expected scale
10k+ users

Make it yours. Open this stack in the editor to check its health, harden it and hand it to your coding agent. No sign-up, nothing to generate.

Start from this stack
goes down

Select a component to see what it does and what it connects to, or pick one above to see what breaks if it goes down. Pinch or use the buttons to zoom.

Why this stack

The JavaScript snippet is served from a CDN and sends events to an ingestion API on Google Cloud Run, which does as little as possible: it puts each event on Google Cloud Pub/Sub and returns. Event workers read from Pub/Sub, write the events to ClickHouse, a column store built for counting billions of rows, keep live visitor counts in Redis and store exports in Google Cloud Storage. The dashboard calls a separate Dashboard API that runs funnel and retention queries on ClickHouse and reads account data from PostgreSQL. Clerk handles sign-in, Stripe bills customers and Sentry reports errors.

Why each piece

All 14 components on the diagram: what each one does, what it talks to, and what stops if it goes down.

  1. Frontend Dashboard

    Next.js analytics UI. Calls Dashboard API, Clerk (auth) and Sentry (errors). Called by Tracking CDN (loads).

    If it goes down, 1 of 13 components stops working.

  2. Tracking CDN

    In Google Cloud Run

    Snippet hosting. Calls Frontend Dashboard (loads) and Ingestion API (sends).

    Nothing else on the diagram depends on it.

  3. Ingestion API

    In Core Services

    Event ingestion. Calls Google Cloud Pub/Sub (publishes) and Sentry (errors). Called by Tracking CDN (sends).

    If it goes down, 1 of 13 components stops working.

  4. Dashboard API

    In Core Services

    Analytics queries. Calls ClickHouse (queries), PostgreSQL (reads), Redis (reads), Clerk (auth) and Stripe (billing). Called by Frontend Dashboard.

    If it goes down, 2 of 13 components stop working.

  5. Event Workers

    In Google Cloud Run

    Async processing. Calls Google Cloud Pub/Sub (consumes), ClickHouse (writes), PostgreSQL (writes), Redis (updates), Google Cloud Storage (stores) and Sentry (errors).

    Nothing else on the diagram depends on it.

  6. Google Cloud Pub/Sub

    Event bus. Called by Ingestion API (publishes) and Event Workers (consumes).

    If it goes down, 2 of 13 components degrade.

  7. Clerk

    In External Services

    Authentication. Called by Frontend Dashboard (auth) and Dashboard API (auth).

    If it goes down, 3 of 13 components stop working.

  8. Stripe

    In External Services

    Billing. Called by Dashboard API (billing).

    If it goes down, 1 of 13 components degrades.

  9. Metrics

    In Logging

    Structured metrics.

    Nothing else on the diagram depends on it.

  10. Redis

    In Data & Storage

    Live state. Called by Dashboard API (reads) and Event Workers (updates).

    If it goes down, 2 of 13 components degrade.

  11. Google Cloud Storage

    In Data & Storage

    Files and exports. Called by Event Workers (stores).

    If it goes down, 1 of 13 components degrades.

  12. PostgreSQL

    In Databases

    App metadata. Called by Dashboard API (reads) and Event Workers (writes).

    If it goes down, 4 of 13 components stop working.

  13. ClickHouse

    In Databases

    Analytics store. Called by Dashboard API (queries) and Event Workers (writes).

    If it goes down, 4 of 13 components stop working.

  14. Sentry

    In Logging

    Error tracking. Called by Event Workers (errors), Frontend Dashboard (errors) and Ingestion API (errors).

    If it goes down, 3 of 13 components degrade.

When this stack fits

  • Event volume is huge, and collecting events must never slow down your customers’ websites.
  • Queries are counts, funnels and retention over months of events.
  • Ingestion and dashboards have to scale separately.

When to pick something else

  • You only need analytics for your own product: an existing analytics tool is far less work than building one.
  • Volumes are modest, in the millions a month: PostgreSQL alone can store and query them.

What you need to build this

14 components across 9 areas of the stack.

Build it with your AI agent

Hand the stack to Claude Code, Codex, Cursor or any coding agent as a brief: how it connects, install steps and a build plan.

Frontend1

  • Frontend Dashboard · Next.js

    Next.js analytics UI

    npm install next

    Docs

Backend & APIs3

  • Ingestion API

    Event ingestion

  • Dashboard API

    Analytics queries

  • Event Workers

    Async processing

Data2

  • ClickHouse

    Analytics store

    Docs

  • PostgreSQL

    App metadata

    Docs

Cache & queues2

  • Redis

    Live state

    Docs

  • Google Cloud Pub/Sub

    Event bus

    Docs

Auth1

  • Clerk

    Authentication

    npm install @clerk/nextjs

    Docs

Payments1

  • Stripe

    Billing

    npm install stripe

    Docs

Storage & CDN2

  • Tracking CDN

    Snippet hosting

  • Google Cloud Storage

    Files and exports

    Docs

Observability1

  • Sentry

    Error tracking

    npm install @sentry/nextjs

    Docs

Other1

  • Metrics

    Structured metrics

Install

npm install next @clerk/nextjs stripe @sentry/nextjs

SDKs only. Pick your own database driver or ORM.

See all 30 example stacks