Wie ich 10xInterview.com als Solo-Entwickler baute – eine Alternative zu Google Interview Warmup

Nach der überraschenden Abschaltung von Google Interview Warmup, einem Tool für KI-gestützte Interview-Vorbereitung mit Sprachaufnahmen und Feedback, blieb bei vielen Nutzern eine Lücke. Doch statt die Hände zu ringen, entwickelte ein Solo-Entwickler eine eigenständige Lösung: 10xInterview.com. Innerhalb eines Jahres entstand eine voll funktionsfähige Plattform – komplett aus einer Hand, mit minimalem Tech-Stack und cleveren Architekturentscheidungen.

Das Projekt beweist, dass hochwertige KI-Anwendungen auch ohne komplexe Microservices-Infrastruktur realisierbar sind. Hier sind die vier zentralen Design-Entscheidungen, die das Projekt nachhaltig prägten und die Codebasis auch nach monatelanger Weiterentwicklung schlank hielten.

Ein bewusst einfacher Tech-Stack als Fundament

Die technische Basis von 10xInterview.com setzt auf bewährte, aber leistungsstarke Komponenten – ganz ohne den Hype um moderne Frameworks oder überflüssige Infrastruktur. Die Wahl fiel auf eine monolithische Architektur mit Go 1.23 als Backend-Sprache und React 19 als Frontend. Die Datenhaltung erfolgt zentral über Postgres 17 mit pgvector-Erweiterung, während die KI-Anfragen über Google Vertex AI (Free-Tier) und Gemini API Pro abgewickelt werden. Für die Sprachverarbeitung kommen Googles Speech-to-Text- und Text-to-Speech-Dienste zum Einsatz.

Die Infrastruktur läuft auf Cloud Run mit zwei Instanzen, Cloud SQL für die Datenbank und Razorpay für die Abrechnung via Webhooks. Ein einzige, idempotenter Shell-Skript reicht aus, um die gesamte Anwendung zu deployen. Keine Redis-Instanzen, keine Kafka-Cluster, keine zweite Vektordatenspeicherung – stattdessen ein Fokus auf Betriebsstabilität und einfache Wartung.

Dynamische KI-Routing-Entscheidungen für verschiedene Nutzerklassen

Ein zentrales Problem bei der Entwicklung war die unterschiedliche Behandlung von kostenlosen und zahlenden Nutzern: Während Free-Tier-Nutzer auf günstige KI-Modelle angewiesen sind, erwarten Premium-Kunden eine hochwertigere Antwortanalyse. Die Lösung lag in einem dualen Backend-Routing-System.

Jede KI-Funktion wird als Interface mit zwei Implementierungen realisiert – eine für den Free-Tier und eine für den Premium-Tier. Ein Router entscheidet zur Laufzeit, welche Implementierung genutzt wird, basierend auf dem Nutzerplan im Authentifizierungskontext. Der Handler selbst bleibt davon unberührt und muss nicht zwischen den Backends unterscheiden.

type Reviewer interface {
    Review(ctx context.Context, in ReviewInput) (ReviewOutput, error)
}

type ReviewerRouter struct {
    Free  Reviewer  // Vertex AI, z.B. Gemini 2.5 Flash
    Paid  Reviewer  // Gemini API Pro
}

func (r *ReviewerRouter) Review(ctx context.Context, in ReviewInput) (ReviewOutput, error) {
    if auth.PlanFromContext(ctx) == auth.PlanPro {
        return r.Paid.Review(ctx, in)
    }
    return r.Free.Review(ctx, in)
}

Diese Architektur bietet drei entscheidende Vorteile:

• Automatische Fallbacks bei Fehlern: Fällt ein Premium-Backend aus, wechselt das System nahtlos zum Free-Tier – ohne dass Nutzer eine Fehlermeldung erhalten.
• Lokale Entwicklung ohne Cloud-Zugang: Durch eine Umgebungsvariable (AGENT_ENABLED=false) lassen sich alle KI-Komponenten als deterministische Stubs nutzen. Neue Entwickler können das Projekt ohne Google-Cloud-Zugang lokal starten.
• Skalierbare Erweiterung: Soll ein weiterer Nutzerplan (z.B. Enterprise) hinzukommen, muss lediglich ein weiteres Feld im Router hinzugefügt werden. Der bestehende Code bleibt unverändert.

Server-Sent Events für Echtzeit-Feedback in Millisekunden

Die erste Version der Plattform verarbeitete Nutzerantworten synchron: Die KI analysierte die Sprachaufnahme, und erst nach 8–14 Sekunden erhielt der Nutzer ein Ergebnis. Zwar funktionierte dieses Modell technisch, doch die Nutzererfahrung litt unter der Wartezeit. Die Lösung lag in Token-Streaming via Server-Sent Events (SSE).

Anstatt auf klassische REST-APIs zu setzen, werden die KI-Ergebnisse nun Token für Token an den Client gesendet. Sobald der erste Token verarbeitet ist, beginnt die Anzeige von Feedback – noch bevor die vollständige Analyse abgeschlossen ist. Dies reduziert die wahrgenommene Wartezeit um etwa 50 %.

Die Architektur des SSE-Brokers ist bewusst minimal gehalten und läuft in-process innerhalb des monolithischen Backends:

type Broker struct {
    mu     sync.RWMutex
    subs   map[string][]chan Event // submissionID -> Abonnenten
}

func (b *Broker) Subscribe(id string) (<-chan Event, func()) {
    ch := make(chan Event, 32)
    b.mu.Lock()
    b.subs[id] = append(b.subs[id], ch)
    b.mu.Unlock()
    return ch, func() {
        // Bereinigung des Abonnenten
    }
}

func (b *Broker) Publish(id string, e Event) {
    b.mu.RLock()
    for _, ch := range b.subs[id] {
        select {
        case ch <- e:
        default: // Verwerfen, falls Abonnent zu langsam
        }
    }
    b.mu.RUnlock()
}

Der Client nutzt die standardmäßige EventSource-API, um die SSE-Verbindung zu öffnen und die Ergebnisse in Echtzeit zu verarbeiten:

const es = new EventSource(`/api/v1/submissions/${id}/stream`);
es.onmessage = (e) => {
    const event = JSON.parse(e.data);
    setReview((prev) => mergeEvent(prev, event));
};

Diese Lösung kommt ohne zusätzliche Infrastruktur wie Redis oder Kafka aus und bleibt auch bei steigendem Traffic performant – solange die Backend-Instanz nicht skaliert werden muss.

Postgres mit pgvector: Warum eine relationale Datenbank reicht

Für zwei zentrale Funktionen benötigte das Projekt eine Vektorsuche:

• Deduplizierung von Interviewfragen: Identische Fragen in verschiedenen Formulierungen (z.B. "Was ist ein Closure?") sollen nicht mehrfach im System landen.
• Resume-Analyse: Lebensläufe sollen semantisch mit Stellenausschreibungen abgeglichen werden.

Anstatt eine spezialisierte Vektordatenspeicherung wie Pinecone oder Weaviate einzusetzen, fiel die Wahl auf Postgres mit der pgvector-Erweiterung. Diese Entscheidung sparte nicht nur Kosten, sondern vereinfachte auch die Wartung.

Die Integration von pgvector in Postgres erfolgt über eine einfache Schema-Erweiterung und ermöglicht die effiziente Speicherung und Abfrage von Vektordaten direkt in der relationalen Datenbank. Für die Deduplizierung von Fragen wird ein Embedding-Modell genutzt, um semantische Ähnlichkeiten zu erkennen und Duplikate zu filtern.

Der Vorteil dieser Lösung liegt in der Konsistenz der Datenbanktransaktionen und der einfachen Skalierbarkeit – ein zentraler Punkt für ein Projekt, das von einem einzelnen Entwickler betreut wird.

Fazit: Weniger Komplexität, mehr Skalierbarkeit

10xInterview.com beweist, dass hochwertige KI-Anwendungen auch ohne überflüssige Infrastrukturkomponenten realisierbar sind. Die Kombination aus einem monolithischen Backend, dynamischem Routing, Echtzeit-Streaming und Postgres-basierter Vektorsuche schuf eine stabile, wartbare und kosteneffiziente Lösung.

Für Solo-Entwickler, die ähnliche Projekte planen, bietet dieser Ansatz eine Blaupause: Setzen Sie auf bewährte Technologien, automatisieren Sie Routing-Entscheidungen und streamen Sie Ergebnisse, um die Nutzererfahrung zu revolutionieren. Die nächsten Schritte könnten die Einführung eines Redis-basierten Brokers für Session-Pinning oder die Integration weiterer KI-Modelle umfassen – doch der Kern der Architektur bleibt robust genug, um diese Erweiterungen ohne Systemumbruch zu tragen.