RelayHub

Enterprise integration work keeps producing the same shape of problem: one system emits an event, another system needs to receive it, and the boundary between them has to survive validation failures, downstream outages, and the occasional need to replay something that failed hours ago. Point-to-point integrations solve this once and then get rebuilt for the next pair of systems.

A visible, reusable answer to 'how do you actually handle a delivery failure in a distributed system' is more convincing than a description of it — this project exists to demonstrate that behavior directly, not just to talk about it.

Kafka is the backbone: incoming events are ingested onto a topic, then move through validation and transformation stages before an outbound delivery step calls the configured target. Failed deliveries are retried with backoff; exhausted retries move the event to a dead-letter path where it can be inspected and replayed. An admin console (backed by Spring Boot and Prometheus-scraped metrics) gives operational visibility into throughput, failure rate, and queue depth. `relayhub-demo-systems` runs alongside the core service as simulated source/target systems that generate continuous demo traffic, so the pipeline has real events flowing through it rather than sitting idle.

• Kafka as the event backbone rather than a simpler point-to-point queue, so ingestion and delivery are decoupled and replay is a first-class operation, not an afterthought.
• A dedicated dead-letter path with manual replay, instead of dropping or silently retrying forever, so a failed event is always something a human can act on.
• An admin console with real metrics (via Prometheus) rather than log-diving as the primary way to understand system health.

• Delivery failures (timeouts, target errors) trigger a bounded retry policy before an event is moved to the dead-letter path.
• Dead-lettered events preserve enough context (payload, error, retry history) to diagnose and manually replay them.

• Prometheus-backed metrics feed the admin console's time-series charts (throughput, success/failure rate, latency).
• Continuous synthetic traffic from `relayhub-demo-systems` keeps those metrics meaningful even without live production integrations.

Live in production, running continuously against synthetic source/target traffic. The RelayHub Live Lab on this site is backed by the same event/pipeline model this project actually implements.

• Kafka's KRaft mode needs a complete, consistent environment-variable set to come up cleanly in a container — partial configuration (e.g. only `advertised.listeners`) fails in ways that look unrelated to the actual missing setting.
• An admin console is only as useful as the metrics wired into it — visibility has to be designed in from the start, not bolted on after the pipeline works.