Microservices & Distributed Systems Language Exercises

A service mesh is a dedicated infrastructure layer that handles service-to-service communication, providing features like load balancing, traffic management, and mutual TLS. Engineers typically say "we're using a service mesh to handle cross-cutting concerns" or "the mesh takes care of retries and circuit breaking at the infrastructure level, so our services don't need to implement that logic themselves."

A bounded context is a clearly delimited boundary within which a particular domain model applies consistently. In conversation you might say "the Order bounded context owns all the logic around order lifecycle — it doesn't bleed into the Inventory context" or "we agreed on explicit contracts at the context boundary so both teams can evolve independently."

Common terms include synchronous vs. asynchronous communication, request-response vs. event-driven, choreography vs. orchestration, and point-to-point vs. publish-subscribe. Typical phrases: "we favour async messaging to avoid tight coupling," "the orchestrator drives the workflow," or "services emit domain events and downstream consumers react independently."

A circuit breaker stops sending requests to a failing service and returns a fallback response instead, preventing cascading failures. A useful analogy: "just like an electrical circuit breaker trips to protect your home, our software circuit breaker opens to protect the rest of the system when one service is unhealthy — it gives that service time to recover."

Eventual consistency means that, given no further updates, all replicas of a piece of data will converge to the same value over time. In technical discussions you might say "we accept eventual consistency in the shopping cart service — reads may be slightly stale, but the system will reconcile" or "we document the consistency guarantees explicitly in our service contract."

Common framing: "microservices give us independent deployability and team autonomy, but they introduce network overhead and distributed systems complexity." You might also hear "we started with a modular monolith to validate the domain model before splitting along service boundaries" or "the operational overhead of a microservices architecture needs to be justified by the scale and team size."

Idempotency means that making the same request multiple times produces the same result as making it once. Engineers say "all our mutation endpoints are idempotent — clients can safely retry without risk of duplicate processing" or "we use an idempotency key in the request header to deduplicate retried payments."

The saga pattern manages data consistency across services without a distributed transaction. You would say "we use a saga to coordinate the multi-step checkout flow — each step publishes an event and, if a later step fails, compensating transactions roll back the earlier steps." The two variants are choreography-based sagas and orchestration-based sagas.

The three pillars of observability are logs, metrics, and traces. Distributed tracing is particularly important, and you would say "we propagate a correlation ID across all service calls so we can reconstruct the full request trace in our observability platform." Other key phrases: "structured logging," "trace context," "span," "p99 latency," and "golden signals" (latency, traffic, errors, saturation).

You would say "this release introduces a breaking change to the /orders endpoint — the response schema removes the legacy field, so consumers must upgrade their client versions before we deploy." Best practice vocabulary includes "semantic versioning," "deprecation notice," "sunset date," "backward-compatible extension," and "contract testing to catch integration regressions early."