Concevez un pipeline qui ingère des événements de clickstream depuis une application web et les rend disponibles pour l'analytique.

Collectez les événements via un endpoint léger vers un log durable comme Kafka ou Kinesis, pour découpler producteurs et consommateurs. Validez contre un schema registry à la frontière et routez les échecs vers un topic de dead letter. Faites atterrir les événements bruts de façon immuable dans du stockage objet, partitionné par date d'événement, puis transformez en couches nettoyée et modélisée. Dédupliquez sur l'identifiant d'événement et indexez tout sur le temps d'événement.

Je commencerais par demander le volume et la latence, parce que cent mille événements par jour et cent mille par seconde ne sont pas le même système, et savoir si quelqu'un a réellement besoin de données à la minute. En supposant un cas normal d'analytique produit, un endpoint collecteur léger écrit dans Kafka, ce qui me donne la durabilité et me permet de rejouer si un consommateur en aval a un bug. À cette frontière, je valide contre un schéma enregistré et je pousse tout ce qui est invalide vers un topic de dead letter avec le motif, parce que jeter des événements malformés en silence signifie s'en apercevoir des mois plus tard. Les événements bruts atterrissent dans du stockage objet partitionné par date d'événement, immuables, et cette couche est la source de vérité depuis laquelle je peux toujours reconstruire. Ensuite, une couche de transformation nettoie, déduplique sur l'identifiant d'événement, découpe en sessions et modélise en tables de faits et de dimensions. Je traiterais les données personnelles dès l'ingestion, en hachant les identifiants utilisateur et en gardant la correspondance dans un magasin restreint, puisque c'est bien plus facile que d'essayer de nettoyer un lac après coup.