Wie PostGIS und DynamoDB-Streams ein Echtzeit-Liefernetzwerk antreiben

Die letzte Meile in der Paketzustellung bleibt eine der größten Herausforderungen für Logistikunternehmen. Studien zeigen, dass jährlich etwa 15 % aller Zustellversuche scheitern – sei es, weil niemand zu Hause ist oder keine sichere Ablage möglich ist. Die Folgekosten für Nachlieferungen summieren sich schnell auf fünf bis fünfzehn US-Dollar pro Versuch. Doch was, wenn die Lösung nicht darin besteht, Kunden zu Abholstationen zu schicken, sondern lokale Mikro-Hubs einzurichten, die Pakete flexibel und auf Wunsch direkt an die Haustür liefern?

Genau dieses Konzept setzt die Plattform Hold·My·Package um, ein B2B-SaaS-Tool für Nachbarschafts-Liefernetzwerke. Lokale Unternehmen wie Reinigungen, Convenience-Stores oder Co-Working-Spaces fungieren als dezentrale Hubs. Scheitert ein Zusteller an der ersten Lieferung, wird das Paket automatisch zum nächsten verfügbaren Hub umgeleitet. Von dort aus organisiert die Plattform eine bedarfsgerechte Zustellung – ohne Umwege für den Kunden.

Die Plattform bietet vier spezialisierte Portale:

• Hub-Betreiber verwalten Paketannahmen, optimieren Lieferrouten und analysieren Performance-Kennzahlen.
• Empfänger planen Zustellzeiten und erhalten Echtzeit-Benachrichtigungen.
• Zusteller profitieren von transparenten Routing-Statistiken und Kosteneinsparungen.
• Netzwerk-Administratoren überwachen mehrere Hubs in einer Stadt.

Technisch basiert die Lösung auf einer modernen Serverless-Architektur: Next.js auf Vercel für Frontend und API, Aurora PostgreSQL Serverless v2 für relationalen Datenbestand inklusive PostGIS-Erweiterung, DynamoDB für Event-Streaming mit Single-Table-Design sowie Lambda-Funktionen und Pusher für Echtzeit-Kommunikation.

Warum zwei separate Datenbanken?

Die Kombination aus Aurora PostgreSQL und DynamoDB löst zwei grundlegend unterschiedliche Anforderungen – eine gemeinsame Datenbank wäre hier ineffizient.

Aurora PostgreSQL fungiert als zentrale Datenquelle. Hier liegen alle relationalen Daten wie Nutzerkonten, Paketinformationen, Hub-Standorte, Lieferpläne und räumliche Analysen. Die PostGIS-Erweiterung ermöglicht dabei geospatiale Abfragen direkt auf Datenbankebene. Row-Level Security stellt sicher, dass jeder Nutzer nur seine eigenen Daten einsehen kann. Materialisierte Views beschleunigen analytische Auswertungen.

DynamoDB übernimmt dagegen das Management des Event-Streams. Jede Statusänderung eines Pakets – von Annahme über Planung bis Zustellung – wird als Ereignis erfasst. Diese Daten müssen in vier verschiedenen Mustern abrufbar sein: als Paket-Timeline, als Nutzer-Feed, als Live-Ansicht des Hubs oder als täglicher Bericht für Zusteller. DynamoDBs Single-Table-Design mit Global Secondary Indexes (GSIs), integrierten Streams und automatischer TTL-Verwaltung eignet sich hierfür ideal.

Die klare Trennung: Aurora verwaltet den aktuellen Zustand, DynamoDB die Ereignishistorie.

PostGIS: Geospatiale Logik direkt in der Datenbank

Drei zentrale räumliche Abfrageoperationen treiben die Kernlogik der Plattform an – und laufen vollständig als SQL-Queries, nicht im Anwendungscode ab:

Routing zum nächsten verfügbaren Hub

Bei einer fehlgeschlagenen Zustellung muss das System den nächstgelegenen Hub mit freier Kapazität finden:

SELECT id, name, ST_Distance(location, ST_MakePoint(-104.99, 39.74)::geography) AS distance_m
FROM hubs
WHERE ST_DWithin(location, ST_MakePoint(-104.99, 39.74)::geography, coverage_radius_m)
  AND current_load < capacity
ORDER BY distance_m
LIMIT 1;

Eine einzige Abfrage berechnet die Entfernung, prüft die Abdeckungszone und filtert nach verfügbaren Kapazitäten – alles in einem Schritt.

Clusterbildung für effiziente Lieferrouten

Ein entscheidender Vorteil für Hub-Betreiber ist die automatische Gruppierung benachbarter Lieferungen in Cluster. Vor der Auslieferung werden Pakete nach räumlicher Nähe und Zeitfenster zusammengeführt:

SELECT 
  ST_ClusterDBSCAN(p.delivery_address::geometry, eps := 500, minpoints := 2) OVER() AS cluster_id,
  p.id,
  p.tracking_number,
  hp.address
FROM packages p
JOIN delivery_schedules ds ON ds.package_id = p.id
JOIN homeowner_profiles hp ON hp.id = p.homeowner_id
WHERE p.hub_id = $1
  AND p.status = 'scheduled'
  AND ds.scheduled_window_start BETWEEN $2 AND $3;

Die Funktion ST_ClusterDBSCAN identifiziert Pakete innerhalb von 500 Metern und bildet daraus effiziente Liefertouren. Der Betreiber sieht sofort: "Drei Pakete in der Market Street – eine Tour, ein Stopp." Ohne externe Optimierungstools übernimmt die Datenbank diese Intelligenz.

Automatische Abdeckungsprüfung

Bei der Kundenregistrierung prüft das System via ST_DWithin, welcher Hub für die Adresse zuständig ist. Gleiches gilt für das automatische Umlenken bei fehlgeschlagenen Zustellungen. Ein räumlicher Operator, mehrere Anwendungsfälle.

DynamoDB: Ein-Tabellen-Design für vier Abfragemuster

Die Plattform nutzt eine einzige DynamoDB-Tabelle mit einem durchdachten Schlüsselkonzept und drei Global Secondary Indexes, um vier völlig unterschiedliche Abfrageanforderungen effizient zu bedienen.

Schlüsselstruktur

• Primärschlüssel (PK): PKG#{package_id}
• Sortierschlüssel (SK): EVENT#{timestamp}#{event_type}
• GSI1 (HomeownerFeed): homeowner_id + timestamp
• GSI2 (HubFeed): hub_id + timestamp
• GSI3 (CarrierDaily): carrier#{date} + timestamp

Abfragen im Überblick:

• Haupttabelle: Vollständige Ereignishistorie für ein einzelnes Paket
• GSI1: Aktivitätsfeed eines Empfängers über alle seine Pakete
• GSI2: Echtzeit-Übersicht aller Vorgänge in einem Hub
• GSI3: Täglicher Zustellerbericht mit allen umgeleiteten Paketen

Bedingte Schreiboperationen

Statusänderungen erfolgen über bedingte Schreibzugriffe, die Konflikte verhindern:

ConditionExpression: 'attribute_not_exists(PK) AND attribute_not_exists(SK)'

Versuchen zwei Anfragen gleichzeitig, dasselbe Ereignis zu schreiben, scheitert eine mit einem ConditionalCheckFailedException. Die Anwendung kann dies abfangen und entsprechend reagieren – ohne verteilte Sperren.

Automatische Löschung mit TTL

Jedes Ereignis erhält einen TTL-Wert von 90 Tagen. DynamoDB entfernt abgelaufene Einträge automatisch. Dies ersetzt manuelle Bereinigungsjobs und sorgt für eine saubere Datenhaltung.

Die Echtzeit-Pipeline: Aurora und DynamoDB im Zusammenspiel

Die Integration beider Datenbanken erfolgt über eine schlankes Event-Verarbeitungssystem. Wenn Aurora einen Statuswechsel vornimmt (mit optimistischer Sperre über eine Versionsspalte), schreibt die API gleichzeitig das Ereignis in DynamoDB. Von dort aus startet eine automatisierte Kette:

1. DynamoDB schreibt das Ereignis
2. Der integrierte Stream löst eine Lambda-Funktion aus
3. Die Lambda verarbeitet bis zu zehn Ereignisse gleichzeitig
4. Über Pusher werden alle verbundenen Clients in Echtzeit benachrichtigt

Die Lambda-Funktion kommt ohne externe Abhängigkeiten aus und ist mit nur fünf Kilobyte Code extrem schlank. Sie liest die Pusher-Anmeldedaten aus Umgebungsvariablen und signiert die Anfragen mit der nativen Node.js-Crypto-Bibliothek. Diese Architektur ermöglicht eine skalierbare Echtzeit-Kommunikation ohne zusätzliche Infrastruktur.

Die Kombination aus geospatialer Datenbanklogik und serverlosem Event-Streaming zeigt, wie moderne Architekturen selbst komplexe Anforderungen wie dynamische Liefernetzwerke effizient und kostengünstig lösen können. Die nächsten Schritte könnten die Integration von KI-gestützten Vorhersagemodellen für optimale Hub-Auslastung oder die Erweiterung um IoT-Sensoren zur automatischen Paketübergabe umfassen.