Guide complet gratuit
Concevez agrégateur de clics publicitaires.
Le rythme de l’entretien reste compact, pour que la page consacre son attention aux vraies décisions de conception.
Ne vous contentez pas d’énoncer les besoins : demandez-les. Chaque carte associe la contrainte de conception à une question de clarification que vous pouvez dire à voix haute avant de dessiner l’architecture.
01Qu’est-ce qui compte exactement comme un clic — le tap de l’utilisateur, ou l’arrivée sur le site de l’annonceur ?
L'utilisateur clique sur une publicité et reçoit une redirection 302 vers le site de l'annonceur — le clic est enregistré côté serveur sur ce saut, si bien que les bloqueurs de pub et les clients instables ne peuvent pas le perdre.
02Quelle granularité et quelle fraîcheur les annonceurs demandent-ils ?
Les annonceurs interrogent les métriques de clics dans le temps à une granularité minimale d'une minute, disponibles environ une minute après le clic.
03Si le même clic arrive deux fois — double-tap ou retry — doit-il compter une seule fois ?
Un clic dupliqué sur la même impression ne compte qu'une fois — chaque publicité affichée porte déjà un impression ID unique.
04Seulement les clics, ou aussi les impressions et le CTR ?
Les clics d'abord. Les impressions et le CTR (click-through rate, taux de clic) viennent plus tard en suite connue.
05Quelles granularités au-delà de la minute — l'heure, le jour ?
Les annonceurs consultent aussi des vues horaires et quotidiennes ; la minute reste la granularité la plus fine.
06Les plafonds de budget doivent-ils arrêter les pubs en quasi-temps réel ?
Oui — une pub qui atteint son plafond de budget doit cesser d'être diffusée en une minute environ.
Hors périmètreLe ciblage et la diffusion publicitaire (quelle pub montrer) · Le suivi de clics multi-appareils · L'intégration de canaux marketing hors ligne
01Pour quel pic de débit de clics devons-nous dimensionner ?
Pic de 10K clics par seconde sans aucune perte. Les données de clic sont des données de facturation, donc le pipeline est construit pour ne jamais perdre un clic.
02À quelle vitesse les tableaux de bord des annonceurs doivent-ils répondre ?
Les requêtes répondent en moins d'une seconde sur des plages de temps arbitraires.
03Quelle fraîcheur les chiffres doivent-ils avoir ?
Quasi-temps réel : un clic doit être interrogeable environ une minute après s'être produit.
04Ces chiffres alimentent directement la facturation, n’est-ce pas — donc aucun sur-comptage n’est acceptable ?
Non — les doublons et les retries ne doivent jamais gonfler les chiffres ; ce sont des chiffres de niveau facturation.
05Quelle exactitude pour les chiffres — un bref écart corrigé ensuite est-il acceptable ?
Une petite erreur transitoire dans les premières minutes est tolérable, mais les chiffres de facturation doivent être exacts et converger en moins d'un jour.
Les vrais entretiens sondent bien plus qu’une liste propre. Ces questions de périmètre séparent ceux qui interrogent le problème de ceux qui le récitent.
Traitez chaque estimation comme une pression qui justifie un composant : cache, file, partition, réplica, pool de workers ou chemin de repli.
Volume d'événements quotidien
Pic de 10K clics/s, ~100M clics/jour100M events × ~100 B ≈ 10 GB/day bruts
Les événements bruts sont peu coûteux à conserver indéfiniment dans un data lake — c'est ce qui rend la réconciliation quotidienne possible.
Nombre de lignes d'agrégats
On suppose ~10M pubs actives × 1 ligne/minute10M pubs × 1,440 minutes par jour (24 h × 60 min) ≈ 14B rows/day au pire — mais seules les pubs ayant des clics émettent des lignes, réalistement ≪ 1%
Des lignes-minute éparses gardent l'OLAP store assez petit pour des scans de plage en moins d'une seconde.
Taille du cache de déduplication
On suppose qu'un impression ID reste valide pour une fenêtre de clic d'~1 heure10K/s × 3,600 s × ~50 B ≈ 1.8 GB
Toute la fenêtre de dédup tient confortablement dans un seul cluster Redis.
Fenêtre de perte si le stream processor meurt
Flink fait un checkpoint une fois par fenêtre-minutecrash → replay depuis le dernier checkpoint ≈ au plus 1 minute recalculée
La rétention Kafka (des jours) plus les checkpoints font qu'un crash de processeur recalcule, ne perd jamais.
Pourquoi ne pas interroger les événements bruts
La table brute de clics vs une requête de tableau de bord annonceur sur 30 joursla table brute grossit de 3B rows/mois ; même une tranche par pub indexée à la granularité minute scanne des millions de lignes par requête — loin du sous-seconde
La pré-agrégation n'est pas une optimisation ici — c'est le design.
Exemple de décision
Dix mille clics par seconde, c'est de l'argent qui entre : chaque clic perdu est une dépense non facturée, et chaque clic compté en double est un annonceur en colère.
Enregistrer le clic sur le saut de redirection et l'écrire dans un stream durable (Kafka) avant toute autre chose. Un processeur de stream agrège ensuite en continu par fenêtres d'une minute et déverse les résultats dans un store OLAP que les tableaux de bord interrogent. Chaque annonce affichée porte un ID d'impression signé, et une vérification Redis élimine les doublons. Une fois par jour, un job batch relit les événements bruts depuis le lake et corrige les chiffres du stream.
Ce que je NE ferais PAS : stocker les clics bruts dans une base de données et lancer un GROUP BY à chaque requête de tableau de bord. Trois milliards de lignes par requête sur 30 jours, ça la tue. Je ne partitionnerais pas non plus le stream purement par ID d'annonce, puisqu'une seule annonce virale fait fondre une partition unique. Le remède est simple : ajouter un suffixe aléatoire aux ID d'annonces chaudes, les étaler sur N partitions, et retirer le suffixe à l'écriture des agrégats. Tout le problème vient du choix de la mauvaise clé de partition.
Si les annonceurs acceptent une fraîcheur de 5 minutes, je supprimerais entièrement la couche de streaming et lancerais des micro-batches — moitié moins de pièces mobiles, même exactitude, juste plus lent.
D’abord une image complète, puis chaque chemin comme son propre schéma — le chemin d’écriture et le chemin de lecture portent un trafic différent et justifient des composants différents.
Image complète
Chemin 1
Chemin 2
Avant d’optimiser, rendez le contrat inspectable : endpoints, entités, propriété, retries et état.
GET/ads/{ad_id}/click?impression_id=
rés302 Location: advertiser_url
Le saut de redirection enregistre durablement chaque tentative, puis le stream processor déduplique par impression_id avant tout agrégat de facturation ou écriture de sink. Un cache peut accélérer les vérifications de doublons, mais l'exactitude de la facturation doit survivre à une perte de cache et à un replay.
GET/metrics?ad_id&from&to&granularity=1m
rés200 [{ minute, clicks, unique_users }]
Servi depuis l'OLAP store, jamais depuis les événements bruts — un GROUP BY sur des milliards de lignes est précisément ce que ce design existe pour éviter.
Entités principales
ClickEventimpression_id (PK) · ad_id · user_id · clicked_at
L'impression ID est frappé quand la pub est affichée et signé en HMAC, si bien que les clics ne peuvent être ni falsifiés ni rejoués.
MinuteAggregatead_id · minute · clicks · unique_users
Ce que sert l'OLAP store ; une ligne par pub par minute.
Choisissez une voie pour le dernier tiers de l’entretien. Chaque voie vous donne le sujet, la question de l’examinateur à laquelle répondre, et le mode d’échec à éviter.
Un utilisateur double-clique, ou un retry se déclenche. Comment le compte reste-t-il à un ?
Chaque publicité affichée porte un impression ID signé : le cache de dédup écarte les répétitions dans la fenêtre de clic, et l’upsert minute est idempotent sur cet ID — un retry ne peut jamais ajouter un second comptage.
Dédupliquer sur user+ad — le retargeting montre légitimement la même pub au même utilisateur à nouveau.
Une seule pub prend soudain la moitié de tous les clics. Quel composant atteint sa limite en premier, et comment répartir la charge ?
Saler la clé chaude — éclater ad_id en ad_id#0..N pour répartir la charge sur les partitions, puis une petite étape de fusion replie les comptes partiels dans une seule ligne minute.
Partitionner le flux par ad ID seul — une pub virale envoie alors chaque événement sur la même partition et crée une clé chaude.
Flink meurt au milieu d'une fenêtre. Combien de clics sont perdus, et comment le savez-vous ?
Rien n’est perdu : Kafka retient les événements bruts, le processeur redémarre depuis son dernier checkpoint et recalcule au plus une fenêtre, et les upserts idempotents écrasent au lieu de compter en double.
Faire confiance au flux comme source de vérité — rétention Kafka plus checkpoints signifient replay, pas perte.
Le streaming agrège déjà en temps réel — qu'ajoute le batch quotidien ?
Les chiffres streamés dérivent — événements tardifs, crashs, bugs. Une fois par jour, le batch relit les événements bruts et écrase chaque minute recalculée : le stream achète la fraîcheur, le batch garantit la facture.
Sauter la réconciliation — une exactitude de niveau facturation ne peut reposer sur un flux au mieux-effort.
Un événement atterrit 5 minutes après son clic. Vers quelle minute compte-t-il, et combien de temps les fenêtres attendent-elles ?
Compter selon l’heure de l’événement, pas l’heure d’arrivée : les fenêtres attendent un retard borné (quelques minutes), et le plus tardif est replié par la réconciliation quotidienne.
Ignorer temps-événement vs temps-traitement — compter par heure d'arrivée déplace discrètement de l'argent entre les minutes.
Expliquez agrégateur de clics publicitaires à voix haute et obtenez une évaluation IA de votre explication.