Operations & Deployment

A container bundles a service with everything it needs to run, so it starts the same way everywhere and doesn't fight with other services sharing a machine over conflicting libraries or versions.

You run two copies of the app - one live, one idle with the new version. Once the idle one is tested and ready, you flip a switch (router/load balancer) so all traffic goes to it. If something breaks, you flip back instantly.

A circuit breaker watches for repeated failures calling another service and, once it sees too many, stops sending new requests for a while so the failing service isn't overloaded and your own service doesn't get stuck waiting.

Service discovery lets services find each other's current network location automatically, instead of using fixed IP addresses that change when instances scale, restart, or move.

A sidecar is a small helper program that runs next to each service and handles all its network traffic — sending, receiving, encrypting — so the service's own code doesn't have to.

The config values live in a separate git repo. A central 'config server' reads that repo and hands values to each service on request. Editing the repo alone doesn't reach running services — they either re-fetch on next restart or must be explicitly told to refresh live.

A Deployment manages the running copies of a service and replaces them gradually during updates, while a Service gives callers one stable address that always points at whichever copies are currently healthy.

You send a new version to a small slice of real users first (like 5%), watch error rates and latency, and only widen the slice if it looks healthy. If it looks bad, you send everyone back to the old version.

If all outgoing calls share one pool of worker threads, a slow dependency can hog every thread, leaving none free for calls to healthy dependencies too. A bulkhead gives each dependency its own separate, limited pool so one slow dependency can't starve the rest.

Adding random jitter to retry delays stops many clients from all retrying at exactly the same moment and slamming the recovering service again; without limits, retries can multiply traffic and make an outage worse.

Client-side: the calling app looks up healthy instances itself and picks one. Server-side: the caller just calls a fixed address, and a separate component (load balancer/proxy) looks up instances and forwards the request.

Consul actively pings each instance, and Eureka's instances periodically say 'I'm alive.' If pings fail or the 'I'm alive' messages stop arriving within a set time window, the registry marks that instance as down and stops handing out its address.

The control plane is the 'brain' that decides the rules for routing and security; the data plane is all the sidecar proxies that actually carry traffic following those rules.

The sidecars on both ends do the encryption handshake for the services automatically, using certificates the mesh hands out and rotates — the app code just sends plain traffic to its own sidecar.

Use an on/off switch that can target a percentage of users, store its state somewhere fast and locally readable rather than deep inside one remote service, and make sure that if the switch-checking system goes down, requests fall back to a safe default instead of failing or exposing the risky new feature to everyone.

With many independently-run services, a bad rollout, resource fights between services, or mismatched versions across services can each cause outages a single app never would; teams mitigate with limits, gradual rollouts, and contract testing.

Feature flags are on/off switches in the code. You can ship new code to production turned off, then flip it on for some or all users later without a new deployment - and flip it back off fast if it breaks.

Each call in the chain gets tagged with a shared trace ID, and each step gets its own ID linked back to whoever called it. Tools like Jaeger stitch these into one timeline showing where time actually went.

Moving retries/timeouts into the mesh means one shared config controls every service's behavior instead of each team writing its own — easier to standardize, but harder for a single service to fine-tune its own special cases, and blind retries can make an outage worse.

A Kubernetes Secret is like a hidden config file with the password stored as-is (just encoded, not encrypted by default), and it doesn't expire. Vault instead hands out a temporary password that auto-expires, so a leak stops working soon. Vault is safer but more complex to run.

You can add more copies of just the busy service instead of the whole app, saving resources, but now you have many separate things to size, monitor, and tune instead of just one.

You replace old servers with new ones in small batches instead of all at once, so there's no downtime, but for a while some users hit the old version and some hit the new one - they both need to work together correctly.

Don't make every service's ability to even start depend on one central system being up right now. Give each service a fallback: a locally cached copy of its last-known-good config it can start from if the central source is unreachable.

The pipeline watches health metrics right after a deploy, and if things look bad (errors spike, requests fail), it automatically switches back to the previous version without waiting for a human to notice.

A shared ID gets attached to a request and passed to every service it touches. If each service logs that ID on every line, you can search for the ID and pull all related lines from every service, in order.

Registries can hand out addresses for instances that already died (stale data), can go down themselves and block all lookups, or can get hammered by every service reconnecting at once after an outage. Mitigations include client-side caching with fallback, retries, and staggered reconnects.

Kubernetes gives every Service a stable name and virtual IP. CoreDNS resolves the name to that IP, and kube-proxy sets up networking rules on each node so traffic to that IP gets sent to one of the healthy Pods behind it - no app-level registry client needed.

The mesh's sidecars automatically record how long calls took and whether they succeeded, for every service, without any app code — but they can't fully trace a request's journey unless the app helps pass along a few tracing headers.

When the overhead of running an orchestrator (people, tooling, complexity) costs more than what you get from it — e.g., a tiny team, very few services, or a workload that doesn't fit the container/orchestrator model well.