Schnelle Postplanung mit DynamoDB: Wie SlothPost Zeit spart

Der indiegame-Entwickler David Zhang stand vor einem typischen Skalierungsproblem: Sein Tool SlothPost sollte automatisierte Social-Media-Posts für Entwickler generieren, die keine Zeit zum Schreiben finden. Doch während die Benutzeroberfläche mit GitHub-, Vercel- und App-Store-Integration funktionierte, brach die Datenbankabfrage unter Last zusammen. Die Lösung lag nicht in komplexem Code, sondern in einer intelligenten Nutzung von DynamoDBs Global Secondary Indexes – genauer gesagt: einem sparsamen GSI.

Das Kernproblem: Eine Datenbankabfrage, die mit der Nutzerzahl explodierte

Jeder Nutzer von SlothPost kann mehrere Produkte verwalten – etwa GitHub-Projekte oder mobile Apps. Jedes dieser Produkte verfügt über einen individuellen Veröffentlichungsplan: "Poste dienstags und donnerstags um 9 Uhr auf X, montags auf Threads." Die Kernaufgabe des Schedulers bestand darin, jede Minute zu prüfen, welche Produkte aktuell einen neuen Post benötigen. Die naheliegende, aber fatale Herangehensweise war ein Full-Table-Scan der gesamten Produkte-Tabelle, gefolgt von einer Filterung nach aktiven Plänen. Bei 10 Nutzern funktionierte das noch reibungslos. Doch ab 10.000 Nutzern verwandelte sich die Abfrage in ein Performance-Desaster – die Datenbank war überlastet, und die Antwortzeiten stiegen ins Unermessliche.

Die Lösung: Ein sparsamer GSI filtert unwichtige Daten automatisch

DynamoDB bietet keine eingebauten Server-seitigen Cron-Jobs, aber es bietet Global Secondary Indexes (GSI) mit einer besonderen Eigenschaft: Ein GSI enthält nur Datensätze, die das Attribut aufweisen, das als Partitionsschlüssel dient. Fehlt das Attribut, wird der Datensatz schlichtweg nicht indexiert. Diese Eigenschaft nennt man einen sparsamen Index.

Zhang nutzte diese Eigenschaft, um die Produkte-Tabelle effizienter zu durchsuchen. Er führte zwei neue Attribute ein:

• scheduleStatus: Dieses Attribut erhält den Wert "active", wenn ein Produkt einen aktiven Veröffentlichungsplan hat. Fehlt das Attribut vollständig, bedeutet das, dass das Produkt keinen Plan besitzt oder dieser pausiert ist.
• nextRunAt: Ein Unix-Timestamp, der den nächsten geplanten Veröffentlichungszeitpunkt angibt. Dieser Wert wird jedes Mal aktualisiert, wenn ein Post generiert wird – basierend auf dem individuellen Zeitplan des Nutzers.

Der GSI wurde mit scheduleStatus als Partitionsschlüssel und nextRunAt als Sortierschlüssel konfiguriert. Die Abfrage des Schedulers sieht nun so aus:

const result = await dynamoDB.query({
  TableName: 'slothpost-products',
  IndexName: 'scheduleStatus-nextRunAt-index',
  KeyConditionExpression: 'scheduleStatus = :active AND nextRunAt <= :now',
  ExpressionAttributeValues: {
    ':active': 'active',
    ':now': Date.now()
  }
});

Das Ergebnis: Die Abfrage durchsucht ausschließlich Produkte mit aktivem Plan, die zum aktuellen Zeitpunkt fällig sind. Es werden keine unnötigen Datensätze gescannt, und der Index bleibt klein, weil nur eine Minderheit der Produkte überhaupt einen Plan hat. Die Performance verbesserte sich dramatisch, und die Kosten sanken, da weniger Datenbankkapazität benötigt wurde.

Ein subtiler Fehler, der einen ganzen Tag kostete

Doch selbst die beste Architektur ist nicht immun gegen logische Fehler. Zhangs computeNextRunAt-Funktion prüfte zunächst die Existenz eines Attributs namens daySchedule.enabled, um zu bestimmen, ob ein bestimmter Wochentag für Posts aktiviert war. Der Fehler lag in der Annahme, dass dieses Attribut überhaupt existiert. In SlothPost wird der Aktivierungsstatus nicht als Boolean gespeichert, sondern als Vorhandensein eines Zeitwerts. Ist für Montag eine Uhrzeit konfiguriert, ist Montag aktiv. Ist die Uhrzeit null, ist Montag deaktiviert. Es gibt also keinen separaten enabled-Schalter.

Die Funktion kehrte daher konsequent null zurück, wenn sie nach daySchedule.enabled suchte. Das hatte zur Folge, dass nextRunAt nie aktualisiert wurde. Der GSI blieb leer, und der Scheduler fand bei jeder Ausführung – trotz korrekter Cron-Logik – nichts vor. Der Fehler war besonders tückisch, weil er keine Fehlermeldung auslöste. Stattdessen arbeitete der Scheduler einfach nichts. Die Korrektur war simpel, aber das Debugging gestaltete sich langwierig:

// Alte, fehlerhafte Logik:
if (daySchedule.enabled) { ... }

// Neue, korrekte Logik:
if (typeof daySchedule.time === 'string') { ... }

Ein weiterer Anwendungsfall: Webhook-Routing mit GSI

Die gleiche Technik kam bei einem zweiten Problem zum Einsatz: der Weiterleitung von Vercel-Webhooks an die richtigen Nutzer. SlothPost ist eine Integration für den Vercel Marketplace. Wenn ein Nutzer sein Vercel-Konto verknüpft, wählt er aus, welches seiner Vercel-Projekte er tracken möchte. Die Projekt-ID wird als vercelProjectId im Produkt-Datensatz gespeichert. Trifft nun ein Deployment-Webhook ein, muss das System den zugehörigen Nutzer identifizieren. Auch hier half der sparsame GSI: Er indexierte nur Produkte mit einer verknüpften vercelProjectId, während Produkte ohne Vercel-Integration einfach ignoriert wurden.

Ein weniger offensichtlicher Stolperstein war die Tatsache, dass Vercel-Webhooks nicht programmatisch über die REST-API erstellt werden können. Versuche, dies zu tun, führten zu einem 403-Fehler. Die korrekte Vorgehensweise bestand darin, den Webhook über die Integration Console von Vercel global zu konfigurieren – eine Information, die nirgends in der offiziellen Dokumentation erwähnt wird. Zhang verlor einen ganzen Tag mit der Suche nach einer API-Lösung, bis er diese Einschränkung entdeckte.

Praktische Tipps für den Einsatz von GSI in DynamoDB

Zhangs Erfahrungen zeigen: Ein sparsamer GSI ist ein mächtiges Werkzeug für alle Anwendungsfälle, bei denen nur eine Teilmenge der Datensätze aktiv oder relevant ist. Die Vorteile sind offensichtlich:

• Schnellere Abfragen: Keine Full-Table-Scans mehr, da der Index nur die relevanten Datensätze enthält.
• Geringere Kosten: Weniger Datenbankkapazität wird benötigt, da der Index klein bleibt.
• Skalierbarkeit: Die Lösung wächst auch mit steigender Nutzerzahl problemlos mit.

Ein kleiner, aber entscheidender Tipp für TypeScript-Entwickler: Die Konfiguration removeUndefinedValues: true im DocumentClient von DynamoDB ist keine Option. Sie ist zwingend erforderlich. Fehlt sie, werden Schreiboperationen mit undefined-Attributen abgelehnt. Der Fehler äußert sich nicht sofort, sondern führt zu stundenlangem Debugging – wie Zhang selbst erfahren musste.

Fazit: Kleine Änderungen, große Wirkung

Die Geschichte von SlothPost zeigt, wie eine scheinbar einfache Optimierung – die Nutzung eines sparsamen GSI – ein kritisches Skalierungsproblem lösen kann. Statt stundenlang an komplexen Algorithmen oder teuren Infrastruktur-Upgrades zu arbeiten, reichte eine clevere Nutzung der vorhandenen Datenbankfunktionen. Die Lektion für Entwickler ist klar: Bevor man zu aufwendigen Lösungen greift, lohnt es sich, die Eigenschaften der eingesetzten Tools genau zu verstehen. Manchmal liegt die Antwort in einer gut durchdachten Index-Strategie – und nicht im Code selbst.