Event-driven microservices
ALB → EKS → Kafka (MSK, 6 partitions, 60 s retention) → consumers → PostgreSQL and OpenSearch.
What this architecture teaches
Event-driven systems put Kafka between services: producers publish and continue, consumers process independently. User-facing latency stays low even when consumers are slow.
Consumer throughput is capped by partitions — six partitions means at most six messages processed at once, however many consumers you run. When producers outpace that, lag grows by produced minus consumed every second.
This topic keeps messages for only 60 seconds. Once the oldest unread message is older than that, it is deleted: lag has turned into data loss.
What to look for
- Producers stay fast: they only wait for the Kafka ack
- At most 6 messages are processed at once (6 partitions)
- Lag grows until messages expire unread (retention loss)
Components
- Web users — Web browser (Traffic source)
ALB — Application Load Balancer (Load balancer)
orders-api — Amazon EKS (Server group)
orders-topic — Amazon MSK (Event stream)
- order-consumer — Worker (Worker)
orders-db — PostgreSQL (Relational DB)
orders-search — Amazon OpenSearch Service (Search engine)