Elevatus ist ein echtes Produkt. Es läuft heute unter elevatus.jobs und handhabt Einstellungsprozesse für Enterprise-Clients und Regierungsministerien im gesamten Nahen Osten. Ich war Teil des Teams, das die Multi-Tenant-Architektur baute, auf der es läuft — während meiner Zeit bei Talentera zwischen 2018 und 2020. Das hier ist der Post darüber, was das wirklich bedeutet — nicht der abstrakte Multi-Tenancy-Talk, den du in einem Stripe-Engineering-Blog findest, sondern die spezifischen, peinlichen, faszinierenden Details des Bauens einer Plattform, bei der ein Regierungsministerium und eine Handelskette dieselbe Codebase, dieselbe Datenbankarchitektur und dieselbe Workflow-Engine teilen, und keiner der beiden jemals wissen darf, dass der andere existiert.
Das Tenant-Isolations-Problem ist kein primär datenbezogenes Problem
Wenn Engineers über Multi-Tenancy nachdenken, denken sie normalerweise zuerst über Daten nach: Shared Tables vs. separate Schemas vs. separate Datenbanken. Das ist real und wichtig. Bei Elevatus verwendeten wir ein Row-Level-Isolations- modell mit Tenant-IDs auf jeder Zeile, kombiniert mit Schema-Level-Separation für bestimmte sensible Konfigurations-Tabellen. Das bringt dir die Grundlagen.
Das eigentliche harte Problem ist Identity und Access. Nicht “kann Tenant A die Daten von Tenant B lesen” — das ist ein Query-Filter. Das harte Problem ist: Wie verwaltest du die Identität eines Users auf einer Plattform, bei der dieselbe E-Mail-Adresse einem Job-Kandidaten gehören könnte, der sich bei drei verschiedenen Tenants beworben hat? Was bedeutet es für diese Person, “eingeloggt” zu sein? Welche Tenant-Konfiguration regelt ihre Sitzung? Was passiert, wenn Tenant A und Tenant B dieselbe Einstellungsrunde für dieselbe Position durchführen, und derselbe Kandidat sich bei beiden beworben hat?
Das sind keine hypothetischen Edge Cases. Im MENA-Recruitment-Markt bewerben sich große Kandidatenpools breit. Regierliche Einstellungsrunden — die zentralisiert und in großem Maßstab durchgeführt werden — können zehntausende von Bewerbern haben, von denen viele sich auch auf Stellen im privaten Sektor auf derselben Plattform beworben haben.
Die Antwort, die wir rund um Keycloak aufgebaut haben: ein federated Identity-Modell, bei dem jeder Tenant sein eigenes Realm hatte, mit Kandidaten, die als Cross-Realm- Identitätstyp existierten. Das Core-Profil eines Kandidaten lebte in einem gemeinsamen Identity-Space. Seine Bewerbungsdaten lebten im Tenant-Realm. Der Auth-Flow war tenant-scoped — man konnte sich nicht an der Oberfläche von Tenant A mit Tenant-B-Credentials anmelden — aber ein Kandidat konnte gleichzeitig aktive Bewerbungen bei mehreren Tenants halten, ohne dass die Plattform widersprüchliche Identitätsdatensätze erstellte. Keycloak’s Realm-Federation und Cross-Realm-Token- Exchange machten das handhabbar. Ohne das hätten wir Identity-Federation von Hand gelöst — die Art Arbeit, die Sicherheitsvorfälle produziert.
Was “KI-gestützt” 2018 bedeutete
Das Elevatus-Pitch enthielt “KI-gestütztes Hiring”, was eine wahre Aussage war — in demselben Sinne, in dem viele wahre Aussagen etwas komplizierter sind als sie klingen.
Wir machten keine Large Language Models. GPT-3 existierte noch nicht. Was wir machten, war eine Kombination aus ML-getriebenem CV-Parsing und -Scoring, Kandidaten-Ranking basierend auf gewichteten Kriterien-Matching, und frühen Experimenten mit Videointerviews-Analyse. Das CV-Parsing war der Teil, der in Produktion wirklich gut funktionierte — strukturierte Daten aus unstrukturierten Lebensläufen über fünf Sprachen extrahieren (Arabisch, Englisch, Französisch, Hindi und ein paar weitere) und diese Daten in ein Kandidaten-Profil normalisieren, das das System gegen Job-Kriterien ranken konnte. Die Herausforderung war damals nicht, dass ML schwer war — es war, dass gelabelte Trainingsdaten für arabisch- sprachiges CV-Parsing wirklich dünn gesät waren, und die Modellqualität das widerspiegelte. Wir bauten eine Feedback-Loop, bei der Recruiter-Entscheidungen (eingestellt / abgelehnt / zur nächsten Phase bewegt) in das Ranking-Modell zurückflossen, was es im Laufe der Zeit auf einer per-Tenant-Basis verbesserte.
Dieser letzte Teil — per-Tenant-Modell-Personalisierung — war architektonisch interessant und operativ nervig. Die per-Tenant-Modell-Variante bedeutete, dass die Recruiter-Entscheidungen eines Regierungsministeriums (wo regulatorische Compliance und Credential-Verifikation das Einstellungsrubrik dominieren) ein Modell formten, das sich deutlich von dem unterschied, das auf den Entscheidungen eines Tech-Unternehmens trainiert wurde (wo Portfolio und demonstrierte Skill dominieren). Das ist das richtige Ergebnis. Es ist auch ein Storage- und Serving- Problem, das nicht existiert, wenn man nur ein globales Modell betreibt. Multi- Tenancy angewendet auf ML-Infrastruktur ist ein ganzer zusätzlicher Satz von Constraints.
Die Videointerview-Analyse war weniger produktionsreif. Natural Language Processing auf video-aufgezeichneten Interview-Antworten, das Zusammenfassungs-Assessments für Recruiter generierte. Es funktionierte. Es war im Rückblick auch die Art System, das viel sorgfältigeres Design rund um Bias und Fairness erfordert hätte, als wir 2018 Tooling dafür hatten. Das Feld hat sich erheblich weiterentwickelt. Was ich sagen werde: Wir stellten Fragen darüber, ob dieses Modell die Vielfalt des Bewerbungspools fair widerspiegelt, bevor diese Fragen mainstream wurden — weil unsere Kunden es verlangten. Regierungsministerien, die unter expliziten Diversitäts- mandaten operieren, stellen spitze Fragen über deine KI-Outputs, und “das Modell hat es so gesagt” ist keine akzeptable Antwort für ein Ministeriumsbüro.
Workflow-Orchestrierung pro Tenant, nicht global
Die Camunda-BPMN-Integration ist eine der strukturellen Entscheidungen, mit der ich aus dieser Periode am zufriedensten bin. Recruitment-Workflows sind wirklich komplex: sie haben bedingte Verzweigungen (wenn die Rolle eine Sicherheitsfreigabe erfordert, füge diese Schritte hinzu), parallele Tracks (technischer Screen und HR-Screen können gleichzeitig laufen), zeitabhängigen Zustand (wenn der Kandidat in 7 Tagen nicht geantwortet hat, löse eine Erinnerung aus, dann eskaliere, dann schließe die Bewerbung), und sie unterscheiden sich radikale zwischen Tenants.
Der Einstellungs-Workflow eines Regierungsministeriums für eine Stelle im öffentlichen Dienst könnte 14 Stufen haben und drei Genehmigungsausschüsse einbeziehen. Der Workflow eines Startups könnte 5 Stufen haben und in einer Woche laufen. Keines davon kann hardcodiert werden. Kein konfigurierbares UI kann beides abdecken. Was du tun kannst, ist beide als BPMN-Process-Definitionen zu modellieren, sie per-Tenant zu speichern und Camunda sie mit demselben Engine ausführen zu lassen.
Das bedeutete, die Workflow-Schicht der Plattform war auf der Process-Definition- Ebene tenant-spezifisch, aber auf der Execution-Infrastruktur-Ebene geteilt. Eine neue Workflow-Variante für einen neuen Kunden hinzuzufügen war ein BPMN-File- Deployment, kein Code-Deployment. Diese Unterscheidung ist enorm wichtig, wenn du Enterprise-Kunden hast, die spezifische Anforderungen haben, und ein Vertriebsteam, das ihnen versprochen hat, dass die Plattform diese Anforderungen handhabt.
Das Onboarding-Problem
Enterprise- und Regierungskunden haben beide lange, schmerzhafte Onboarding- Prozesse. Aber sie sind auf unterschiedliche Arten schmerzhaft.
Enterprise-Kunden wollen Integrationen: SSO über ihren bestehenden Identity Provider, Webhooks in ihr ATS oder HRIS, Custom Branding, API-Zugang für ihre internen Tools. Sie haben Developer. Sie können ein Webhook-Payload debuggen. Das Onboarding- Problem ist eines der Konfigurierbarkeit — wie viele Knöpfe exponiert die Plattform, und wie gut dokumentiert sind sie.
Regierungskunden wollen Compliance: Datensouveränitäts-Dokumentation, Sicherheits- bewertungen, formale Genehmigung für spezifische Features. Sie haben oft Beschaffungsprozesse, die älter sind als SaaS. Sie können On-Premise-Deployment- Optionen oder dedizierte Infrastruktur statt gemeinsamer Cloud erfordern. Sie haben Rechtsteams, die Fragen stellen, die deine Standardgeschäftsbedingungen nicht antizipiert haben.
Eine Plattform zu bauen, die beide Typen gleichzeitig onboarden kann, ist ein Produkt- und Architektur-Problem, das sich nicht lösen lässt, indem man die Plattform konfigurierbarer macht. Man braucht organisatorische Muskelkraft neben der technischen Fähigkeit — Leute, die Beschaffung verstehen, die die Dokumentation produzieren können, die ein Regierungssicherheitsreview erfordert, die “wir brauchen ein Datenverarbeitungsabkommen, das dem lokalen Datensouveränitätsgesetz entspricht” in tatsächliche Plattform-Constraints übersetzen können. Der Code ist der einfachere Teil.
Was ich anders machen würde
Die Mobile-Schicht — zunächst Ionic, später Flutter — wurde als separate Produktoberfläche hinzugefügt, und das sah man ihr an. Mobile-first-UX-Muster für Recruitment sind grundlegend verschieden von Desktop-Mustern. Kandidaten- Erfahrung auf Mobile (bewerben, Bewerbungsstatus verfolgen, Videointerviews auf dem Telefon machen) hat andere Constraints als Recruiter-Erfahrung auf Desktop (hunderte Kandidaten reviewen, Batch-Entscheidungen treffen, Einstellungsrunden durchführen). Wir bauten die Mobile-Erfahrung als eine Adaption der Web-Erfahrung, was bedeutete, dass sie nie ganz so gut war wie ein nativ-mobile-first-Produkt gewesen wäre.
Wenn ich das heute designen würde, würden Kandidaten-Erfahrung und Recruiter- Erfahrung als separate Produkte mit separaten Design-Constraints behandelt, die zufällig ein Backend teilen. Die API-Schicht wäre von Anfang an mit beiden Konsumenten im Sinn designed worden, nicht nachträglich angepasst, um Mobile zu unterstützen. Das ist die Standard-”API-First”-Lektion, die jeder einmal auf die harte Tour lernt.
Regierungen nutzen Elevatus tatsächlich. Dieser Satz landet anders, wenn man den Beschaffungsprozess, die Sicherheits-Reviews, die Anpassungs-Verhandlungen und die Integrationsarbeit durchlaufen hat, die bis zum “tatsächlich nutzen” führt. Das ist kein MVP, das von einem freundlichen Early Adopter verwendet wird. Das ist Produktionssoftware, die kritische Prozesse für Institutionen ausführt, die keine Downtime tolerieren können.
Das habe ich gebaut.