Distributed event processing · Affiliate platform
Affitor
An affiliate platform on Node.js and AWS ECS where the hard part is paying the right partner exactly once — across domains, without third-party cookies, on a pipeline that guarantees only at-least-once delivery.
- Delivery guarantee
- At-least-once
- Accounting guarantee
- Exactly-once
The problem
Affiliate platforms live or die on attribution. A click happens on one domain, the conversion happens on another, third-party cookies are largely gone, and every partner is financially motivated to dispute the result. The pipeline also has to absorb bursty event traffic without dropping or double-counting anything — a lost event is an unpaid partner, a duplicated one is an overpayment. The delivery guarantees available are at-least-once; the accounting requirement is exactly-once. Everything else follows from that gap.
What I built
Built a first-party, cross-domain attribution flow that re-establishes identity without third-party cookies — which changes what evidence exists at conversion time, and therefore how the attribution rules themselves have to be written.
Processed clicks and conversions as an event pipeline keyed by deterministic idempotency keys, so a retry, a duplicate delivery and a late redelivery all converge on the same single result.
Made the attribution decision itself deterministic and replayable, so a disputed payout can be recomputed from the event log rather than argued from a dashboard.
Used Redis for the hot attribution-window lookups that would otherwise hit PostgreSQL on every single event, keeping the write path free for the accounting that has to be durable.
Ran containerised services on AWS ECS so ingest capacity scales with event volume rather than with a fixed box, which matters when traffic arrives in partner-driven bursts.
Architecture
An event-driven pipeline where correctness under retry matters more than raw throughput. The idempotency boundary sits at ingest, so everything downstream can assume each event is processed once.
Capture
Pipeline
Infrastructure
Data
What was hard
Attribution without third-party cookies
The industry default stopped working. The flow had to re-establish identity across domains using first-party mechanisms only — which changes what evidence you have at conversion time, and therefore how attribution rules must be written. This is a data-modelling problem disguised as a browser problem.
Exactly-once accounting on an at-least-once pipeline
The delivery guarantees available are at-least-once; the accounting requirement is exactly-once. Idempotency keys plus deterministic event handling close that gap — the key has to be derived from the event's own content rather than assigned on receipt, or a redelivery generates a fresh key and pays out twice.
Bursty traffic against durable writes
Event volume is not smooth: a partner campaign launches and ingest steps up immediately. The read path could absorb that in Redis, but the payout ledger has to be durable, so the work was in keeping the hot lookups off PostgreSQL without letting the accounting path go eventually-consistent.
Business impact
- Attribution survived the deprecation of third-party cookies without a drop in measurable conversions.
- Duplicate and retried events stopped producing duplicate payouts.
- Disputed attributions became answerable from the event log rather than from opinion.
- Ingest capacity scales with event volume on ECS instead of requiring manual provisioning.
Technologies
Working on something like this?
I'm open to senior Shopify and full stack roles. Tell me what you're building.