Don't Panic — Microservices Fundamentals

A microservice is a deployable program that handles one focused business capability and talks to other programs over a network. That description sounds tidy because it leaves out the wires, the timeouts, and the part where the network develops opinions. The point is not to create a charming village of tiny applications. The point is to make one capability changeable without moving every other capability at the same time.

Before this arrangement, one application could keep its rules, database access, and calls in one deployment. A service boundary trades that local convenience for a contract between owners. An order service can own order lifecycle rules. A catalog service can own product information. Split by business capability and the boundary has a job; split by technical layer and each ordinary change becomes a small committee meeting with packets.

The surprise is that a remote call is not a function call wearing a hat. It has latency, partial failure, retries, and the unpleasant possibility that the other side completed the work just before the reply vanished. An idempotent operation can tolerate a retry without repeating its effect. That is why timeouts, bounded retries, load shedding, and fallback behavior belong in the design rather than in a box labeled “later, probably.”

Data also refuses to remain politely local to a diagram. A service that owns its data model cannot rely on a shared database as its hidden integration contract. When a business process crosses services, a saga uses local transactions and compensating actions instead of one shared transaction. When a read needs several services, API composition or a materialized view provides an application-level answer. Eventual consistency is therefore a user-visible behavior, not an invisible plumbing detail.

A fleet of services needs automated delivery, routing, identity, secrets, health checks, logs, metrics, traces, and clear on-call ownership. A gateway or service mesh can help with traffic and telemetry; neither can choose a good boundary or authorize a business action on your behalf. The practical test is pleasantly unromantic: extract a service only when independent delivery, scaling, fault isolation, or ownership gives a measurable benefit. Keep a monolith when it keeps change and operations clearer.

Read the intro for the architecture and tradeoffs, the slides for the relationship map, and the cheatsheet when choosing a communication or data pattern. The Field Notes tab names the operational costs that diagrams tend to misplace. The exercise then lets one request cross a real local boundary, carry trace context, and fail in a way that is visible instead of theatrical.