Architecture multi-services, moteur d'enchère, pipeline analytics et SDKs publisher
Moteur d'enchère publicitaire temps réel
Ad-exchange local : enchère en mémoire (Rust), catalogue et auth (Go), événements Redpanda → ClickHouse, pacing budgétaire via Dragonfly.
- Rust
- chemin chaud enchère
- anti-dup
- annonce unique par page
- pacing
- budget daily / lifetime
Contexte
Plateforme de diffusion d'annonces dans un fil catalogue : chaque emplacement déclenche une enchère indépendante, avec reporting annonceur / publisher et console admin.
Le problème
Un CRUD de campagnes ne suffit pas : il faut une décision d'enchère rapide, un catalogue synchronisé en RAM, un pacing qui coupe une campagne quand le budget est épuisé, et un pipeline d'événements (impression / clic) séparable du chemin chaud.
L'approche
- Service d'enchère Rust : catalogue en mémoire, ciblage et clearing ; chemin chaud découplé du CRUD campagnes.
- API campagnes Go (auth JWT, rôles, sync catalogue vers le moteur).
- Events via Redpanda (Kafka-compatible) consommés vers ClickHouse pour CTR / dépenses / reporting.
- Pacing budgétaire dans Dragonfly (plafonds daily/lifetime, fail-open si cache indisponible).
- SDK publisher web + cœur mobile Rust exposé via UniFFI ; règle anti-répétition d'annonce sur une même page.
Pourquoi ce choix
Rust sur le chemin d'enchère pour la latence et la sûreté mémoire ; Go pour le CRUD et l'itération produit ; Redpanda/ClickHouse pour l'analytics sans alourdir le bid path.
Résultat mesuré
- Socle local opérationnel : campaign-api + ad-engine + event-consumer + dashboard
- Pacing budgétaire et pipeline événements (Redpanda → ClickHouse) implémentés
- SDK publisher avec déduplication d'annonces par page