Traffic routing, attribution, and postbacks on your server
Visits move through an inspectable source, campaign, flow, rule, route, lander, offer, conversion, and callback chain on infrastructure the operator controls.
128 MB and 256 MB resource profiles · seven recorded SIGKILL recovery scenarios
How the pieces connect
- Traffic source
- Campaign and flow
- Rules and route
- Lander and offer
- Conversion
- Postback and report
The job
Performance teams need to know not only that a conversion happened, but why a visitor took a route and which callback was sent afterward.
The hard part
Keep hot routing fast, retain raw facts durably, apply caps and rotation predictably, and recover accepted work after a crash.
How I built it
- Compile routing decisions separately from operator configuration.
- Keep a durable journal and raw Parquet facts before deriving reports.
- Make conversions and outgoing callbacks idempotent.
- Test restart behavior with hard process kills, not only graceful shutdowns.
What I verified
- Source, campaign, rule, route, lander, offer, conversion, and postback lifecycle
- Caps, rotation, schedules, exports, and live operator view
- RocksDB journal, Parquet facts, and DuckDB reports
- Seven recorded SIGKILL recovery scenarios
Current state: Current testing covers one self-hosted node and seven hard-crash recovery scenarios. Multi-node operation and a production SLA are not included.