80% Latenzreduktion bei 10.000+ Bestellungen/Tag

Problem

Die monolithische .NET-Core-Bestellplattform stieß bei Spitzenlast (10.000+ Bestellungen/Tag) an Latenzgrenzen — Checkout- und Katalog-Endpoints litten unter paralleler Nutzung.

Lösung

Zerlegung des Monolithen in Redis-basierte Microservices, RabbitMQ für asynchrone Workloads, Cache-Aside-Patterns und Projection Queries gegen PostgreSQL — 80% Latenzreduktion auf kritischen Endpoints.

Architektur

$ render architecture.mmd

flowchart LR
  Client[Web / Mobile] --> GW[API Gateway]
  GW --> Orders[(Orders Service<br/>.NET Core)]
  GW --> Catalog[(Catalog Service)]
  GW --> Pricing[(Pricing Service)]
  Orders --> Q{{RabbitMQ}}
  Q --> Worker[Image Workers<br/>Python · Flask]
  Orders -- cache-aside --> Redis[(Redis)]
  Catalog -- projection --> Redis
  Orders --> DB[(PostgreSQL)]
  Catalog --> DB
  Worker --> S3[(Object Storage)]
  classDef cache fill:#7f1d1d,stroke:#ef4444,color:#fff
  classDef queue fill:#78350f,stroke:#f59e0b,color:#fff
  classDef db fill:#1e3a8a,stroke:#3b82f6,color:#fff
  class Redis cache
  class Q queue
  class DB,S3 db

Technische Entscheidungen

$ git log --oneline decisions/

#01

Cache-aside statt Read-through

Cache-aside hielt Schreibpfade einfach und vermied Kopplung zwischen Cache und Service-Code. Redis-Miss-Rate fiel unter 8% bei Hot-Reads.

#02

Async statt Sync bei schweren Tasks

Bildverarbeitung, Marktplatz-Push und Inventory-Sync liefen über RabbitMQ-Worker — Order-Request-Pfad blieb unter 200ms p95.

#03

Projection Queries auf PostgreSQL

Breite Read-Endpoints projizierten nur die für UI benötigten Felder — weniger Payload, keine N+1-Joins in EF Core.

#04

Onion Architecture pro Service

Jeder Microservice besaß seinen Domain-Kern; Infrastruktur (Redis/EF) nur in der äußeren Schale — testbare, portable Logik.

Ähnliche Herausforderung?

Lass uns sprechen