Engagement- und multimodale Labeling-Plattform in großem Maßstab

Problem

Das Unternehmen brauchte zwei Dinge, die unabhängig aussehen, bis sie Infrastruktur teilen: ein soziales Engagement-Produkt, das Web2- und Web3-Identität überspannte, und eine Labeling-Pipeline, die multimodale Medien in dem Volumen aufnehmen konnte, das große KI- und Medienkunden erwarten. Keines der beiden Probleme ist als Demo interessant. Beide werden es bei Nebenläufigkeit, Identität und Worker-Durchsatz.

Vorgaben

Das Engagement-Produkt musste sich wie ein sozialer Graph anfühlen, nicht wie ein Ledger-Explorer. Der Labeling-Pfad durfte nicht an eine einzelne Browser-Sitzung gebunden sein, wenn er Kundenvolumen halten sollte. Dienste mussten unabhängig deployen und skalieren. Die beiden Produkte konnten Identität und Infra-Muster teilen, ohne Produktoberflächen zu teilen.

Architektur

Ein graphgestütztes soziales Modell in Neo4j, ausgeliefert über eine GraphQL-API. Kubernetes-Dienste besaßen die Schreib- und Lesepfade, sodass Engagement und Labeling auf eigenen Achsen skalieren konnten. Electron-Desktop-Worker verbanden sich mit einem zentralen Index- und Modellsystem, deshalb saß der Labeling-Durchsatz nicht in einem Tab fest. Engagement-Produkt und Labeling-Produkt teilten Identität und Cluster-Muster; sie teilten keine Oberfläche.

Rolle

Ich habe an der GraphQL-Oberfläche gearbeitet, am Graphmodell, an den Kubernetes-Diensten und an der Verbindung der Worker in das zentrale Indexsystem. Die Aufgabe war, das soziale Produkt kohärent zu halten, während der Labeling-Pfad ein Volumen annahm, das eine reine Browser-Pipeline nicht überlebt hätte.

Ergebnisse

• 400.000 aktive Nutzer im Engagement-Produkt.
• Die Labeling-Pipeline lief mit dem Durchsatz, den Kunden im Maßstab von Adobe / Google / OpenAI erwarten. Das ist eine Aussage über das Betriebsvolumen, keine persönliche Empfehlung dieser Unternehmen.
• Desktop-Worker lösten das Labeling vom Browser, sodass der Durchsatz mit dem Worker-Pool wachsen konnte.

Stack