PROJECT / Backend / Queues
Event Processing Core
A resilient backend for high-volume events with explicit retries, idempotency, and observability.
BackendQueuesObservability
- STATUS
- maintained
- YEAR
- 2026
- ROLE
- Backend Engineer
- STACK
- Java · Kafka · Redis · PostgreSQL
SYSTEM / ARCHITECTURE
How it fits together
- 01Ingress API
- 02Durable event log
- 03Idempotent workers
- 04Dead-letter workflow
- 05Operations console
- Events / minute
- 180k
- Duplicate effects
- 0
- Recovery time
- < 4m
Why it exists
A reliable event system has to assume delivery will be repeated, workers will crash, and downstream services will slow down.
- At-least-once delivery
- Backpressure
- Traceable retries
Design
Every consumer uses an explicit idempotency boundary. Retry state and dead letters are queryable, while lag and failure reasons are observable per event type.
- Transactional outbox
- Bounded exponential retry
- Replay-safe handlers
Operational result
Operators can now answer what failed, why it failed, and whether replay is safe without reading raw logs.