Mercator Relay

A financial-transaction event platform that makes idempotency, delivery state and controlled failure visible, from HTTP intake to Kafka and the audit ledger.

Local engineering build · synthetic demonstration data

Mercator Relay local synthetic control room showing recent signals and a selected event delivery journey
Retained local control-room screenshot, cropped to the event ledger and selected journey. Synthetic frontend adapter; replay controls do not issue backend commands. The screenshot is separate from the dated backend verification below.
6backend integration tests
PostgreSQL and Kafka Testcontainers
3Angular tests
Selection, filtering and local command state
4browser checks
Desktop/mobile flow, overflow and axe
2Terraform contracts
Mocked provider; no AWS account

Why this build.

Mercator makes the path of a transaction event inspectable: acceptance, persistence, publication, delivery and controlled failure.

The first slice stays in one modular deployable. Package boundaries are explicit; independent services wait for a real deployment or scaling reason.

Prove the failure path before adding scale.

Event, audit entry and outbox intent commit together. Delivery is at least once, with destination-level deduplication, bounded retries and an explicit dead-letter path.

One commit. An inspectable delivery path.Event, audit entry and outbox intent commit together. Publication leads to destination-level delivery, with bounded retries and a dead-letter path.

One commit. An inspectable delivery path.

  • Accept
  • Atomic commit
  • Publish
  • Deliver

Destination deduplication · bounded retries · dead-letter path

The event route

  1. Accept

    Validate the envelope and bind an idempotency key.

  2. Commit

    Write the event, audit entry and outbox intent atomically.

  3. Publish

    Claim pending outbox rows and route them through Kafka.

  4. Deliver

    Dedupe per destination or exhaust into the dead-letter path.

The stack and the reason.

The stack responds to Java, messaging, Angular, cloud and infrastructure-as-code signals in target-employer material. Each tool has a defined role in the same bounded slice.

Java 21 + Spring Boot 4.1
Enterprise Java depth alongside the .NET project.
PostgreSQL + Flyway
Database constraints carry idempotency, audit and delivery history.
Kafka 4.3.1
At-least-once routing, bounded retries and a visible dead-letter path.
Angular 22 + signals
Strict TypeScript and browser evidence in a second frontend ecosystem.
Terraform + AWS contract
Private ECS, encrypted RDS and IAM-authenticated MSK, tested without apply.

Implemented boundaries.

  • Atomic persistence

    Event, audit and outbox intent commit together.

  • Observable routing

    Publish, retry and dead-letter transitions remain inspectable.

  • Real dependencies

    Testcontainers exercises PostgreSQL and Kafka, not substitutes.

  • Cloud contract

    Terraform is mocked and tested; a paid deployment is not implied.

The evidence checkpoint.

Docker health, one complete delivery route, Prometheus output and npm audit were checked in the 15 July 2026 local checkpoint. Backend Testcontainers and control-room verification were refreshed on 07 September 2026: six integration tests, three Angular checks, a build and four browser checks. The AWS design has not been applied, and the Angular replay control does not claim a backend command that does not exist.

  • Docker route reached DELIVERED at the 15 July checkpoint.
  • No serious or critical axe findings at the 15 July checkpoint.
  • npm audit reported zero vulnerabilities at the 15 July checkpoint.
  • Terraform remains dated 15 July 2026: provider mocks only, no AWS apply.
  • Local repository; not presented as a deployed production system.

This case study is kept outside search indexing. The repository is local, and these checkpoints establish local behaviour.

Continue through the engineering projectsLumen Observatory