/ Layer 1
Funnel-Frontend
Edge-cached statische Seite + Lightweight-API
Stateless. Schreibt nur in eine Queue. Antwortet jedem Bewerber sofort, auch wenn der Hintergrund 30 Sekunden später noch kaut.
Alle ArtikelWenn der Bewerbungsfunnel
/ Skalierung · Funnel-Architektur
Wenn der Bewerbungsfunnel
200 000 Anfragen pro Quartal schluckt.
Anatomie einer Pipeline, die nicht kippt, auch wenn Marketing am Montag dreht. Warum Standard-CRMs an dieser Last brechen — und was wir stattdessen bauen.
9 Min. Lesedauer12. Mai 2026Case-Hintergrund: Omid
Ein Bewerbungsfunnel sieht nach Frontend aus. Drei Schritte, schicker Progress-Bar, fertig. Stimmt — solange Sie 50 Bewerbungen pro Tag bekommen. Bei 2 500 am Tag wird daraus ein Verteilungs-Problem, eine Compliance-Frage und ein Backend-Albtraum. Spätestens dann zerlegt es jedes Standard-CRM.
Dieser Text beschreibt, was wir gebaut haben, um genau das zu verhindern — am Beispiel eines Funnels, der inzwischen über 200 000 Anfragen pro Quartal verarbeitet, ohne dass jemand im Team „Backlog" sagen muss.
/ Im Einsatz
- 200 K+
- Bewerbungen pro Quartal
- < 200 ms
- Antwortzeit pro Funnel-Schritt
- 6 Stufen
- vom Eingang bis zur Auswahl
- 0 manuell
- Sortierschritte für Standardfälle
Warum Standard-CRMs hier verlieren
Wer das Wort „CRM" hört, denkt an Salesforce, HubSpot, Pipedrive. Alle drei sind exzellent — für Vertriebs-Pipelines mit hunderten Leads im Monat. Bei einem Bewerbungsfunnel mit Massen-Inflow brechen sie an drei Stellen:
- API-Limits. Standard-CRMs versuchen, jede Bewerbung einzeln zu persistieren. Das geht gut bis irgendwann das Daily-Quota schreit. Spätestens bei einem Marketing-Push fängt die Pipeline an zu droppen.
- Workflows als Trigger. „Wenn Status = neu, dann E-Mail." Schön — bis 5 000 Trigger gleichzeitig laufen wollen. Die Workflow-Engine ist nicht für Echtzeit-Massenverarbeitung gebaut.
- Datenmodell. Ein Bewerbungsprozess ist kein linearer Sales-Funnel. Er hat Verzweigungen, Ausschlusskriterien, Quoten pro Standort, Compliance-Pflichten. Das in ein Sales-CRM zu pressen erzeugt technische Schulden bei jedem Release.
„Ein Funnel mit Massenlast ist kein Marketing-Tool. Er ist eine Hochlast-API mit Conversion-Layer obendrauf."
Die Architektur, die nicht kippt
Was wir stattdessen bauen, ist immer dieselbe Form mit unterschiedlichen Geschmäckern. Drei Layer, klar getrennt, jeder mit eigenem Skalierungs-Verhalten:
/ Anatomie der Pipeline
/ Layer 2
Worker-Pool
Background-Jobs mit Idempotenz-Key
Validierung, Anti-Spam, Score-Berechnung. Skaliert horizontal — wenn 5 000 Anfragen reinkommen, drehen wir die Worker auf 50 statt 5.
/ Layer 3
CRM & BI
Postgres + Read-Replicas + analytisches Schema
Hier sitzt das CRM-Modell, in dem die Recruiter arbeiten. Schreibrate kontrolliert über Worker, nicht über User-Traffic.
Der Trick ist die Entkopplung von User-Traffic und Datenbankschreiben. Der Bewerber wartet nie auf das CRM. Die Recruiter sehen die Bewerbung ein paar Sekunden später — Konsistenz statt Echtzeit.
Conversion ist Architektur
Conversion-Optimierung wird oft als Design-Disziplin verkauft — bessere Texte, weniger Felder, klarere Buttons. Stimmt alles, aber der größte Hebel liegt im Backend.
Wenn der nächste Funnel-Schritt 1,8 Sekunden zum Laden braucht, verlieren Sie pro Sekunde Wartezeit ca. 7 % der Bewerbenden. Bei sechs Schritten ist das katastrophal. Sub-200ms Antwortzeit ist nicht Polish — es ist Pflichtprogramm.
Das gilt auch für Heatmap-Insights. Wir messen pro Funnel-Schritt:
- Time-on-step (Median + 95-Perzentil)
- Klick-Pfade (welche Buttons werden vor dem Submit getestet?)
- Drop-off-Quote relativ zum vorherigen Schritt
- Validierungsfehler-Häufigkeit pro Feld
Diese Daten landen täglich in einem BI-Dashboard, das genau drei Personen lesen — und nach dem Lesen Felder umsortieren oder entfernen. Conversion-Optimierung ist ein dauerhafter Prozess, kein einmaliger A/B-Test.
Die DSGVO-Falle, die niemand bedenkt
Bewerbungsdaten sind besonders schützenswerte Daten. Das hat zwei Konsequenzen, die in vielen Projekten zu spät erkannt werden:
/ Risiko
Standard-Cloud-Tools speichern oft außerhalb der EU. Bewerbungsdaten in einem US-CRM ohne saubere SCCs sind Art. 28-DSGVO-Wackelware.
/ Lösung
Hosting in deutschen Rechenzentren, dokumentierte Löschfristen pro Bewerbungsstatus, automatische Anonymisierung nach Ablauf. Bewerber-Auskunfts-Self-Service als API-Endpoint.
Die zweite Konsequenz: automatisches Scoring ist gefährlich. Sobald ein Algorithmus über die Vorauswahl von Bewerbenden entscheidet, sind Sie im Geltungsbereich von Art. 22 DSGVO (automatisierte Einzelfallentscheidungen). Wir bauen Scoring ausschließlich als Sortier-Hilfe, nie als Filter — Menschen entscheiden, Maschinen ranken.
/ Fazit
Ein Funnel, der nicht kippt, sieht für den Bewerbenden langweilig aus: drei Schritte, kurze Wartezeit, freundliche Bestätigung. Die ganze Architektur dahinter merkt er nie.
Genau das ist das Ziel. Wenn Sie ähnliche Lasten erwarten oder ein Standard-Tool gerade die Grenzen seines Designs erreicht, sprechen wir gerne.
/ Weiterlesen