Kerninformationssysteme

Logistik ist Echtzeit-Geschäft. Eine Sendung, die 5 Minuten im System verloren geht, verursacht eine Kaskade von Problemen — falsche Sortierung, Lieferverzögerungen, SLA-Strafen. Wir bauen WMS und Logistik-IS, bei denen jede Sendung jederzeit einen klaren Status und einen klaren Weg hat.

Event-driven Architektur ist das Fundament. Jeder Scan, jede Umsortierung, jede Beladung erzeugt ein Event in Apache Kafka. Nachgelagerte Systeme (Tracking, Abrechnung, Reporting) konsumieren Events unabhängig. Der Ausfall eines Systems stoppt nicht die Sortierung — Events warten in Kafka und werden nach der Wiederherstellung verarbeitet.

Durchsatz und Latenz: Unsere WMS-Systeme verarbeiten 10.000+ Sendungen/Stunde in einem einzelnen Hub. API-Latenz unter 50ms bei P95. Horizontale Skalierung über Kubernetes — Kapazitätserweiterung in Minuten, nicht Tagen. Lasttests mit k6 simulieren Weihnachtsspitzen Monate im Voraus.

Hardware-Integration: Sortierlinien, Scan-Tore, Waagen, Etikettendrucker. Wir kommunizieren über OPC-UA, REST API und proprietäre Protokolle. Edge Processing auf Geräten gewährleistet Funktionalität auch bei Netzwerkausfällen — Daten synchronisieren sich nach Wiederherstellung der Konnektivität.

Praxisbeispiel: Für ein Logistikunternehmen mit 15 Hubs haben wir ein monolithisches System durch Event-driven Architektur ersetzt. Ergebnis: 3× höherer Durchsatz, MTTR von Stunden auf Minuten, null Sendungsverluste im System. ROI in 8 Monaten.

Transaktionssysteme haben keinen Platz für „fast funktioniert”. Wenn eine Zahlung zur Hälfte durchgeht, haben Sie ein Problem. Wir bauen Systeme mit ACID-Garantien, bei denen jede Transaktion entweder vollständig ist oder gar nicht stattgefunden hat. Keine inkonsistenten Zustände, kein verlorenes Geld.

Architektur für Zuverlässigkeit: Saga Pattern für verteilte Transaktionen über mehrere Services. Outbox Pattern für garantierte Event-Zustellung. Idempotente API — wiederholte Anfragen verursachen keine doppelten Transaktionen. Dead Letter Queue für fehlgeschlagene Nachrichten mit automatischem Retry und Alerting.

HA/DR-Design: Active-Passive mit automatischem Failover (RTO < 30s). Synchrone Replikation für null Datenverlust (RPO = 0). Regelmäßige DR-Tests — nicht einmal im Jahr auf dem Papier, sondern automatisierte monatliche Failover-Drills. Georedundanz für kritische Systeme.

Audit und Compliance: Jede Transaktion mit vollständigem Kontext protokolliert — wer, was, wann, woher. Unveränderliches Audit-Log (Append-Only). Der Regulator bekommt den vollständigen Trail in Minuten, nicht Tagen. Kompatibel mit CNB-, PSD2- und DORA-Anforderungen.

Leistung unter Last: Wir verarbeiten Tausende Transaktionen/Sekunde mit konstanter Latenz. Connection Pooling, Prepared Statements, optimierte Indizes. Lasttests simulieren den Black Friday 2× im Voraus — wir kennen das Limit, bevor wir es erreichen.

Ein Treueprogramm ist ein Kernsystem, kein Marketing-Gadget. Wenn ein Kunde bezahlt und die Punkte nicht innerhalb von 5 Sekunden erscheinen, ruft er den Kundenservice an. Wenn ein Partner keine aktuellen Daten hat, verweigert er den Rabatt. Wir bauen Loyalty-Plattformen, die Millionen von Kunden in Echtzeit bedienen.

Echtzeit-Verarbeitung: Punkte werden im Moment der Transaktion gutgeschrieben, nicht im nächtlichen Batch. Event-driven Architektur — POS-System sendet Event, Loyalty Engine verarbeitet Regeln (Multiplikatoren, Bonusaktionen, Tier-Upgrades), der Kunde sieht den aktualisierten Status sofort. Latenz < 200ms End-to-End.

Rules Engine: Flexible Regeln ohne Deployment — das Marketing-Team richtet Kampagnen ein (2× Punkte am Wochenende, Bonus bei Einkauf über 1000 CZK, Partner-Multiplikator), das System wendet sie sofort an. Regelversionierung, A/B-Testing von Kampagnen, Echtzeit-Performance-Reporting.

Partnerintegration: REST API für Partner mit OAuth2, Rate Limiting, Webhook-Benachrichtigungen. Partner fragt Punktestand ab, wendet Rabatt an, meldet Transaktion. SLA pro Partner, Monitoring pro Endpunkt. Typischerweise 10–50 Partner, jeder mit eigenen Regeln.

Skalierung: Millionen von Kunden, Dutzende Millionen Transaktionen monatlich. Redis für Hot Data (aktuelle Punkte, Tier), PostgreSQL für Historie. Horizontale Skalierung — das Hinzufügen eines neuen Partners verlangsamt bestehende nicht. DSGVO-Compliance — Recht auf Löschung, Datenportabilität, Consent Management.

Big-Bang-Rewrite ist Glücksspiel, keine Strategie. 70 % großer Rewrite-Projekte scheitern oder überschreiten das Budget um 2×+. Wir modernisieren schrittweise — Strangler-Fig-Pattern, bei dem das neue System schrittweise Funktionen des alten übernimmt. Jeder Schritt ist deploybar, testbar und rollbackfähig.

Unser 7-Schritte-Playbook: (1) Stabilisierung — Monitoring, Metriken, Baseline. (2) Domain Mapping — Event Storming, Bounded Contexts, Abhängigkeitsanalyse. (3) API Gateway — Fassade vor dem Legacy, Routing-Regeln. (4) Isolation des ersten Moduls — kleinster Bounded Context mit den wenigsten Abhängigkeiten. (5) Datenmigration — CDC (Change Data Capture), Dual-Write, Reconciliation. (6) Schrittweiser Rollout — Canary Releases, Traffic Shifting 5 % → 25 % → 50 % → 100 %. (7) Decommission — altes Modul aus, Monitoring des neuen.

Datenmigration ist der schwierigste Teil. Legacy-Systeme haben Jahre angesammelter technischer Schulden in den Daten — inkonsistente Formate, fehlende Validierung, Duplikate. Wir verwenden CDC (Debezium) für Echtzeit-Replikation, Reconciliation-Jobs für Konsistenzprüfung und einen Rollback-Plan für jeden Schritt.

Risikomanagement: Jeder Modernisierungsschritt hat definierte Erfolgskriterien, Rollback-Plan und Kommunikationsprotokoll. Feature Flags trennen Deploy von Release — der Code ist in Produktion, aber das Feature ist deaktiviert, bis es die Validierung bestanden hat. Wir ändern nie mehr als ein Modul gleichzeitig.

Reale Ergebnisse: Typische Modernisierung dauert 6–18 Monate (abhängig von der Größe). Bringt Mehrwert ab dem ersten Quartal — besseres Monitoring, schnellere Deployments, reduzierte Betriebskosten. TCO sinkt typischerweise um 30–50 % durch Wegfall der Legacy-Wartung.

Microservices ohne DDD sind ein verteilter Monolith. Die Aufteilung von Services nach technischen Schichten (Auth Service, Notification Service) statt nach Domänen führt zu enger Kopplung, verteilten Transaktionen und Deployment-Hölle. DDD definiert Service-Grenzen nach Geschäftsdomänen — jeder Bounded Context hat eine klare Verantwortung.

Event Storming als Discovery-Tool: Bevor wir eine Zeile Code schreiben, machen wir Event Storming mit Domänenexperten. 2–3 Tage Workshops, in denen wir Geschäftsprozesse abbilden, Aggregates, Bounded Contexts und Domain Events identifizieren. Ergebnis: Systemlandkarte, die sowohl Business als auch Technik verstehen.

Event Sourcing & CQRS: Für Domänen, in denen Sie eine vollständige Historie benötigen (Finanzen, Audit, Compliance), verwenden wir Event Sourcing — der Zustand wird aus der Event-Historie berechnet, nicht aus dem letzten Snapshot. CQRS trennt Lesen von Schreiben — Read Model optimiert für Abfragen, Write Model für Geschäftslogik.

Organisatorische Skalierung: Conways Gesetz besagt, dass die Architektur die Organisation kopiert. Mit DDD drehen wir es um — Bounded Contexts definieren die optimale Teamstruktur. Jedes Team besitzt seinen Context, seine Deployment-Pipeline, sein SLO. Team Topologies in der Praxis.

Anti-Patterns, die wir vermeiden: Gemeinsame Datenbank zwischen Services (enge Kopplung). Synchrone Aufrufketten (Kaskadenausfälle). Zu kleine Services (Nano-Services-Overhead). God Service, der alles weiß. Verteilte Transaktionen über 5+ Services.

Deployment sollte kein Ereignis sein. Wenn Ihr Team ein „Deployment-Fenster” am Sonntagabend hat und alle in Bereitschaft sind, stimmt etwas nicht. Wir bauen Deployment-Pipelines, bei denen Push auf Main Routine ist — automatisiert, getestet, mit sofortigem Rollback.

Blue-Green Deployment: Zwei identische Umgebungen. Neue Version wird auf „Green” deployed, getestet, Traffic wird umgeschaltet. Wenn etwas fehlschlägt, schalten wir in Sekunden auf „Blue” zurück. Kein Downtime, kein Stress. Für Kubernetes verwenden wir Argo Rollouts mit automatischen Health Checks.

Canary Releases: Neue Version bekommt 5 % Traffic. Automatische Metriken (Fehlerrate, Latenz, Business-KPI) entscheiden, ob auf 25 %, 50 %, 100 % fortgefahren wird — oder Rollback. Gesamter Prozess automatisiert, menschliches Eingreifen nur bei Eskalation. Typischerweise 30–60 Minuten vom Push bis zum vollständigen Rollout.

Feature Flags: Trennung von Deploy und Release. Der Code ist in Produktion, aber das Feature ist deaktiviert. Wir schalten schrittweise ein — interne Nutzer → Beta → 10 % → 100 %. A/B-Testing eingebaut. Kill Switch für jedes Feature. LaunchDarkly, Unleash oder maßgeschneiderte Lösung nach Bedarf.

Datenbank-Migrationen: Riskantester Teil des Deployments. Wir verwenden das Expand-Contract-Pattern — zuerst neue Spalte hinzufügen (Expand), dann Daten migrieren, dann alte entfernen (Contract). Keine Breaking Changes, keine Table Locks. Flyway/Liquibase mit automatischen Rollback-Skripten.