Segment

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build the event pipeline I actually need instead of Segment — and start by counting your destinations, because that number decides everything.

**Hundreds of maintained integrations is what the price buys.** Almost nobody uses hundreds. Most companies send events to a warehouse, one analytics product and one email tool — and three destinations written directly is less code than the configuration describing them.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A worker for delivery, separate from the ingest process
- Caddy in front

THE DATA MODEL
- events: id, message_id, name, kind, user_id, anonymous_id, properties_json, context_json, sent_at, received_at — kind is track, identify, page or group
- identities: anonymous_id, user_id, at — the stitch
- destinations: id, name, kind, config_encrypted, filter_json, is_active
- deliveries: id, event_id, destination_id, status, attempts, response_excerpt, next_attempt_at, delivered_at
- **The event table is the point.** Everything downstream is a copy; this is the original, and it is what makes replay possible

INGEST
- One endpoint, one shape. Follow the established spec — track, identify, page, group — rather than inventing one, because every client library already speaks it
- **A message id on every event, generated by the client**, and ingest deduplicates on it. Networks retry, and without this a purchase is counted twice
- Answer in a couple of milliseconds: validate, write, return. Delivery happens in the worker
- Reject an event with no name or no identifier rather than storing something unusable
- A size cap and a rate limit per key

DELIVERY, WHICH IS WHERE THE WORK IS
- One adapter per destination: map the event to that service's shape, send it, report what happened. A small module with a fixture and a test each
- Retries with exponential backoff and jitter, and a dead-letter list with a one-button replay
- **Idempotency downstream**: pass the message id through where the destination supports it, so a retry does not create a second record. Where it does not, say so in the adapter, because that is a fact somebody will need
- Per-destination filters, so a marketing tool does not receive every server-side event and a warehouse receives all of them
- Rate limits respected per destination, with the API's own headers honoured

REPLAY, WHICH IS THE FEATURE PEOPLE DISCOVER LATE
- Because every event is stored, a destination added in March can be sent January's events
- That is one query and the same delivery path. It is the strongest argument for owning the pipeline rather than sending straight to each tool from the browser
- Guard it: replaying a million events into a service with a rate limit is a good way to be blocked, so it is queued and throttled like everything else

THE SCHEMA, WHICH IS THE PART THAT DECIDES WHETHER ANY OF IT IS USEFUL
- A tracking plan: the events you send, their properties and their types, in a file in a repository
- Validate on ingest and **record violations rather than rejecting them** — a dropped event is invisible, a recorded violation is a bug report
- Without this, two engineers send 'Signup Completed' and 'signup_completed' with different properties, and six months later no report is trustworthy

PRIVACY
- Personal data in properties is the default failure. Decide what may be sent, enforce it in the plan, and strip the rest at ingest
- Deletion by user identifier across the event store, and a record of which destinations were told

WHAT MATTERS MOST
The stored event table and the message id. The first gives you replay and makes every destination replaceable; the second stops a retry becoming a duplicate purchase.