Kajota Pulse: Wie eine KI-gestützte Handelsplattform ohne Passwörter funktioniert

Die Herausforderung für afrikanische Mikrounternehmer wie Co-Seller ist nicht das Erstellen von Produktlisten, sondern die Frage: Was sollte ich diese Woche kaufen? Kajota Pulse, ein Gewinnerprojekt des AWS × Vercel-Hackathons, beantwortet diese Frage mit einer Terminal-ähnlichen Handelsplattform, die KI-gestützte Empfehlungen liefert – komplett ohne Passwörter und Server.

Eine Handelsplattform mit KI-Fokus

Co-Seller in afrikanischen Mikrohandelsnetzwerken kaufen Waren bei Großhändlern ein und verkaufen sie mit Aufschlag an ihre lokale Gemeinschaft. Während bestehende Tools vor allem bei der Erstellung von Produktbeschreibungen helfen, fehlt eine Lösung, die die entscheidende Frage beantwortet: Welche Produkte lohnen sich diese Woche zu bestellen? Kajota Pulse nutzt künstliche Intelligenz, um Händlern datenbasierte Einkaufsempfehlungen zu geben.

Das Projekt ist Teil eines dreiteiligen Ökosystems:

• Coach erstellt Produktlisten.
• Pulse analysiert Markttrends und gibt Kaufempfehlungen.
• Mesh wickelt den Verkauf über Blockchain-Technologie ab.

Der Hackathon hatte eine besondere Vorgabe: Die gesamte Anwendung musste auf dem sogenannten Zero Stack laufen – also ohne eigene Serververwaltung. Dabei kamen Vercel für die Berechnung, AWS Aurora Serverless v2 für die Datenhaltung und KI-Modelle von Google Gemini zum Einsatz. Doch die größte Hürde war nicht die Entwicklung der Benutzeroberfläche, sondern die technische Umsetzung im Hintergrund.

Serverless und Aurora: Warum Passwortlosigkeit zur Pflicht wird

AWS Aurora Serverless v2 wurde mit einem neuen Netzwerkmodell konfiguriert, das direkte Internetverbindungen ermöglicht – ohne Virtual Private Cloud (VPC). Doch genau diese Konfiguration erzwang eine unerwartete Änderung: Die Datenbank akzeptiert keine herkömmlichen Passwörter mehr. Stattdessen muss eine kurzlebige Authentifizierung über AWS Identity and Access Management (IAM) erfolgen.

Der Grund liegt im neuen Internetzugangsmodell von Aurora Serverless v2. Es unterstützt zwar den direkten Zugriff, aber ohne Unterstützung für RDS Data API und mit der Anforderung, dass nur IAM-basierte Authentifizierung möglich ist. Das bedeutet: Jede Datenbankverbindung benötigt ein 15-minütiges Authentifizierungstoken, das dynamisch generiert wird.

Hier der relevante Ausschnitt aus dem Code:

const signer = new Signer({ 
  hostname, 
  port, 
  username, 
  region, 
  credentials 
});

pool = new Pool({
  host, 
  port, 
  user, 
  database, 
  password: () => signer.getAuthToken(), // Dynamisches Token pro Verbindung
  ssl: { rejectUnauthorized: false }
});

Die PostgreSQL-Bibliothek pg unterstützt einen asynchronen Callback für das Passwort, sodass die Verbindung sicher und ohne langlebige Passwörter in Umgebungsvariablen oder Geheimnis-Managern auskommt. Das Ergebnis ist eine Architektur, in der kein dauerhaftes Datenbankpasswort an irgendeiner Stelle gespeichert werden muss.

AWS-Anmeldedaten in Vercel: Wenn Lambda eigene Identitäten überschreibt

Ein weiteres Hindernis war die Integration der AWS-Anmeldedaten in die Vercel-Umgebung. Die Anwendung benötigt AWS-Zugangsdaten, um die IAM-Tokens zu signieren. Obwohl diese in Vercel als Umgebungsvariablen gesetzt wurden, scheiterte die Authentifizierung.

Der Grund: Vercel-Funktionen laufen auf AWS Lambda, und Lambda überschreibt die Umgebungsvariablen `AWS_ACCESS_KEY_ID` und `AWS_SECRET_ACCESS_KEY` mit den eigenen Ausführungsrollen-Credentials. Das führte dazu, dass die Signatur nicht mit der richtigen Berechtigung (rds-db:connect) erfolgte.

Die Lösung bestand darin, die AWS-Credentials unter eigenen Umgebungsvariablennamen zu speichern und diese explizit an die Signaturfunktion zu übergeben:

function signerCredentials() {
  const accessKeyId = process.env.PULSE_AWS_ACCESS_KEY_ID;
  const secretAccessKey = process.env.PULSE_AWS_SECRET_ACCESS_KEY;

  return accessKeyId && secretAccessKey 
    ? { accessKeyId, secretAccessKey } 
    : undefined;
}

Es wurde ein dedizierter IAM-Benutzer mit eingeschränkten Berechtigungen (rds-db:connect) erstellt, der nur für diese Anwendung genutzt wird. Die Credentials wurden unter PULSE_AWS_* gespeichert, um Konflikte mit Lamba zu vermeiden. Dadurch funktionierte die Authentifizierung zuverlässig.

Echtzeit-Datenströme: Warum Seed-Daten bei der Entwicklung trügen können

Um sicherzustellen, dass die Empfehlungen aktuell und präzise sind, wurden drei MongoDB Atlas Database Triggers auf die Produktkataloge (products, cosell_products, orders) angewendet. Jede Änderung in diesen Sammlungen löst einen Webhook aus, der die Daten in die PostgreSQL-Datenbank von Aurora überträgt.

Doch die Verwendung echter Produktionsdaten brachte unerwartete Probleme ans Licht, die bei Testdaten mit Seed-Dateien nie aufgetreten wären:

• Extended JSON-Format: Atlas überträgt Daten im EJSON-Format. Eine MongoDB-ID kommt als {"$oid":"…"} an, während ein Preis als {"$numberInt":"9500"} übertragen wird. Ohne Dekodierung führt dies zu id="[object Object]" und price=NaN in der Datenbank. Zwei kleine Helferfunktionen (ejsonId, ejsonNum) lösten das Problem.

• Namenskonventionen: Die tatsächliche Sammlung hieß cosell_products (mit Unterstrich), doch die Router-Regeln erwarteten cosellproducts. Die Events wurden ignoriert. Eine Normalisierung der Sammlungsnamen war erforderlich.

• Fremdschlüssel und Ereignisreihenfolge: Change-Stream-Events kommen nicht in der Reihenfolge an, in der sie erzeugt wurden. Ein Referenzeintrag in cosell_products kann eintreffen, bevor der dazugehörige Eintrag in products existiert. Fremdschlüssel-Constraints führten zum Verlust dieser Daten. Die Lösung: Fremdschlüssel wurden entfernt, und jede Tabelle wird nun als unabhängige Projektion behandelt.

Diese Probleme zeigen, warum echte Datenströme unverzichtbar sind. Sie decken Fehler auf, die bei statischen Testdaten unsichtbar bleiben.

Von der Datenbank zur KI-Empfehlung: Wie die Anwendung Entscheidungen trifft

Kajota Pulse geht über eine reine Datenvisualisierung hinaus. Die Anwendung nutzt Google Gemini 2.5 Flash, um aus den aktuellen Marktdaten konkrete Kaufempfehlungen zu generieren. Der Prozess läuft wie folgt ab:

1. Die API /api/recommend sammelt Live-Daten wie Nachfrageentwicklung, Margen, Wettbewerbsaktivitäten und Lagerbestände.
2. Diese Daten werden an das KI-Modell übergeben, das mit einem strukturierten Ausgabeschema antwortet:

Bio-Shea-Butter → Bestelle 10–15 Einheiten vor dem Wochenende. "+27 Favoriten, befindet sich in der hochmargigen Kategorie Beauty (18%), und ein Mitbewerber hat gerade eine ähnliche Creme ausverkauft."

Zwei technische Details sorgen für Stabilität:

• Strukturierte JSON-Ausgabe: Durch die Angabe von responseMimeType: "application/json" und eines responseSchema wird sichergestellt, dass die Antwort direkt in die Anwendung integriert werden kann – ohne aufwendige Textparsing-Algorithmen.
• Fallback-Algorithmus: Sollte das KI-Modell nicht verfügbar sein, springt ein heuristischer Algorithmus ein, der Nachfrage, Marge und Marktchancen kombiniert. Dadurch bleibt die Anwendung auch bei Ausfällen nutzbar.

Fazit: Zero Stack als Booster für Innovation

Die Entscheidung für eine Zero-Stack-Architektur brachte mehrere Vorteile mit sich:

• Keine Serververwaltung: Vercel übernimmt die Berechnung, Aurora die Datenhaltung. Es gibt keine Patches oder Skalierungsprobleme.
• Erhöhte Sicherheit: Durch die IAM-basierte Authentifizierung entfällt die Notwendigkeit, Passwörter zu speichern oder zu verwalten.
• Echtzeit-Anpassungsfähigkeit: Die Integration von Echtzeit-Datenströmen stellt sicher, dass die Empfehlungen stets aktuell sind.

Projekte wie Kajota Pulse zeigen, wie moderne Technologien die Entwicklung von Lösungen für reale Probleme in Schwellenländern beschleunigen können. Die Kombination aus KI, Serverless-Architekturen und datengetriebenen Empfehlungen könnte den Mikrohandel in Afrika nachhaltig verändern – und das alles ohne den Ballast traditioneller Serverinfrastrukturen.