← Microservices Pattern Demo

Glossary

This page provides an explanation for the technical terms used across this demo and its companion pages - the Azure guide, Part 2, and the pattern catalogue.

Architecture patterns

API Gateway. A single entry point that sits in front of several services and routes each request to the right one. Callers only ever talk to the gateway, never to the services behind it directly.

Cache-Aside. A pattern for reading a value that changes far less often than it’s read. A read checks a cache first; if it’s not there, the real data store is read and the cache is filled in before returning. A write doesn’t update the cache directly - it deletes the cached value, so the next read repopulates it fresh.

CQRS (Command Query Responsibility Segregation). Keeping the model used to make changes separate from the model used to answer reads. The read side can be built in advance from events, shaped exactly for the questions it needs to answer, rather than computed live from the same tables the write side uses.

Database-per-service. Each service keeps its own database, with no other service reading or writing to it directly. The only way to work with another service’s data is to ask that service for it.

Publish-subscribe (pub/sub). One service announces that something happened (an “event”) without knowing or caring whether anything is listening. Any service that wants to react to that event subscribes to it separately. The two sides are never directly connected.

Saga. A way of handling a multi-step operation that spans more than one service’s database, where there’s no single transaction covering both. Each step either completes normally or is undone by a matching “compensating” step if something later in the sequence fails.

Compensating transaction. The “undo” step in a Saga - reversing a change that already happened, because a later step in the same operation failed. In this demo: giving back stock that was reserved for an order that ended up being rejected.

Circuit breaker. A safeguard around a call to another service. After several failures in a row, it stops even attempting the call for a short period and fails immediately instead - so a dependency that’s genuinely down doesn’t get hit with the full cost of every request on top of already being down.

Retry. Trying a failed call again, a small number of times, before giving up - for failures that are likely temporary (a brief network hiccup) rather than permanent. Not used for failures that trying again could never fix, like being told there isn’t enough stock.

Idempotent. Doing something twice has the same effect as doing it once. Matters for anything that might be retried or redelivered - a duplicate shouldn’t double the result.

Observability and tracing

Trace. The full record of one request’s journey through a system - every step it took, in every service it passed through, tied together under one ID.

Span. One step within a trace - a single piece of work, with a start time, an end time, and whatever it was waiting on.

Trace context propagation. Carrying a trace’s identifying information along with a request or event as it moves between services, so every step ends up recorded under the same trace instead of looking like several separate, disconnected ones. Doesn’t happen automatically across an asynchronous event - see the Part 2 and pattern catalogue pages for why.

OpenTelemetry. An open, vendor-neutral standard for producing traces (and other telemetry) from application code - this demo uses its Python library directly, rather than a vendor-specific one.

OTLP. The network protocol OpenTelemetry uses to send traces to wherever they’re stored - Jaeger, in this demo.

Jaeger. An open-source tool for storing and browsing traces. This demo’s gateway makes it reachable at /jaeger/.

Technology used in this demo

Container. A packaged, self-contained way of running one piece of software, with everything it needs to run already included. Each service in this demo runs in its own container.

Docker Compose. A way of describing several containers and how they connect, in one file, so the whole set can be started together with one command.

Redis. An in-memory data store. This demo gives it two unrelated jobs on the same instance: a publish-subscribe message broker, and a Cache-Aside cache - neither aware the other exists.

SQLite. A small, file-based database, with no separate database server to run. Each service in this demo has its own SQLite file.

TTL (time-to-live). How long a cached value is kept before it’s treated as stale and discarded, regardless of whether anything has invalidated it directly.

Azure-specific terms

Only relevant to the Azure guide and Part 2 on Azure - the main demo and its other companion pages don’t use any of these.

Azure Container Apps. A managed service for running containers, without having to manage the servers underneath them yourself.

Azure Service Bus. A managed message broker - the durable, persistent equivalent of this demo’s own Redis pub/sub, used in the Azure version so an event published while its consumer is down isn’t lost.

Managed identity. An identity Azure assigns to a service itself, rather than a service using a shared password or key. Lets each service be given only the specific permissions it actually needs.

PostgreSQL Flexible Server. A managed PostgreSQL database service - the Azure equivalent of each service’s own SQLite file in the Docker Compose version.

Application Insights. A managed service for collecting and browsing traces and other telemetry - the Azure equivalent of this demo’s own Jaeger instance.

Dapr. A set of building blocks (including retry and circuit-breaker policies) that can be attached to a container as configuration, instead of being written into the application’s own code.