Hoang Le
Sheet 01 of 08Analytics ingestion redesign
Back to plate 01

One wire protocol, four apps

I redesigned Aepsy's product analytics ingestion from WebSocket to authenticated HTTP batch, across a Node collector, a Spring Boot consumer and four client apps, with a versioned wire protocol and a typed event registry. I rebuilt the collector on Fastify, replacing NestJS, with rate limiting, bot heuristics and per-event rejections, and wrote the TypeScript SDK at 97% line coverage, cut from 14.4 KB to 6.6 KB gzip.

Period
May 2026 - Present
Role
Software engineer, AepsyContract, Remote, Switzerland
Stack
TypeScript, Node.js, Fastify, Spring Boot
Proof

Pipeline

Fig. 1
Fig. 1Four client apps run the TypeScript SDK and send authenticated HTTP batches across the versioned wire protocol to the collector, which applies rate limiting, bot heuristics and per-event rejections ahead of the consumer. Struck through: the old WebSocket path.

Facts

01 to 06

  1. Ingestion moved from WebSocket to authenticated HTTP batch across a Node collector, a Spring Boot consumer and four client apps.

    From my CV, Aepsy

  2. A versioned wire protocol and a typed event registry.

    From my CV, Aepsy

  3. The collector was rebuilt on Fastify, replacing NestJS, with rate limiting, bot heuristics and per-event rejections.

    From my CV, Aepsy

  4. The TypeScript SDK has 97% line coverage.

    From my CV, Aepsy

  5. The SDK was cut from 14.4 KB to 6.6 KB gzip.

    From my CV, Aepsy

  6. Google Cloud Pub/Sub is part of the Aepsy stack.

    From my CV, Aepsy stack

Fig. 2Aepsy TypeScript SDK, gzip, before and after the cut. Lengths are to scale.

Why it is hard

One protocol change has to land across a collector, a consumer and four client apps that do not release together, two of them at app store cadence.

Second thread

HR system simulator

A third-party system, simulated

For a partner integration at Aepsy I built a simulator of a third-party HR system: a multi-tenant PostgreSQL schema and migrations, typed repositories, REST endpoints and HMAC-signed, idempotent webhooks.

Fig. 3Two independent lanes. REST endpoints: the integration under test calls the simulator's REST endpoints, which sit on typed repositories over the multi-tenant PostgreSQL schema and its migrations. Webhooks: the simulator sends a signed webhook and its retry to the integration; each passes the HMAC check, and the idempotency check applies the webhook and stops the retry as a duplicate.

Facts 07 to 09

  1. A simulator of a third-party HR system for a partner integration.

    From my CV, Aepsy

  2. Multi-tenant PostgreSQL schema and migrations, typed repositories.

    From my CV, Aepsy

  3. REST endpoints and HMAC-signed, idempotent webhooks.

    From my CV, Aepsy

Why it is hard

An integration against a system you do not control is only testable if you can stand up an honest copy of it, signatures and retries included.