PBO Tech

Reference architecture · runnable demo

Microservices Pattern Demo

API Gateway, database-per-service, and publish-subscribe, wired together as a small running system rather than a diagram - with distributed tracing across the event boundary, where it's easiest to lose.

Live
How it works

Three small services sit behind one gateway. Placing an order below walks the whole architecture in one request:

  1. The browser calls POST /orders on the API Gateway (nginx) - the only thing it ever talks to directly.
  2. The gateway routes that to orders-service, which writes the order to its own SQLite database (orders.db) - no other service can read this table directly, by design.
  3. orders-service then publishes an order_created event to Redis and returns straight away. It has no idea whether anything is listening.
  4. inventory-service happens to be subscribed to that event. On receiving it, it decrements stock in its own database (inventory.db) - entirely independently; it could be stopped, redeployed, or replaced without orders-service ever noticing.
  5. Both services export OpenTelemetry spans to Jaeger. Redis pub/sub doesn't carry trace context on its own, so orders-service injects the current trace into the event payload before publishing it, and inventory-service extracts it to continue the same trace rather than starting a new, disconnected one. That's why the link below shows one trace spanning both services, not two unrelated ones.

Place an order below, then follow its trace link into Jaeger to see that whole sequence laid out as spans.

Place an order

Open Jaeger →

Inventory

Orders

Order IDItemQty