Microservices

DabbaGo now has 40 engineers in five teams, all working in one application. The rider team finished a small fix on Monday, but it cannot ship until the payments team finishes testing its own changes, because everything is released together. Every Thursday release night brings a queue of anxious teams and a long rollback if anything breaks. The code is fine; the problem is that everyone is tied to everyone else.

The rule

One team, one service, one database, one deploy button.

Microservices split a system into small services, each built around one business capability, such as Ordering, Payments or Delivery. The defining properties:

• Independently deployable. The Delivery service can be released on Monday without waiting for anyone.
• Owns its data. Each service has its own database or schema. Other services never read its tables directly; they ask through its API or listen to its events.
• Owned by one team. The team that builds a service runs it, from code to production alerts.
• Simple pipes. Services talk through plain HTTP calls or a message broker. The rules live in the services, not in the connections, which is a deliberate contrast with a central bus holding business logic in SOA.

Service boundaries usually follow bounded contexts from domain-driven design. Ordering, Kitchen and Delivery each have their own meaning of "order", so each can become a service.

The costs are large, and they arrive immediately:

• Every call between services is now a network call that can be slow or silent.
• Data is spread out. A report joining orders and deliveries needs events or copies, and consistency across services becomes eventual.
• Operations multiply. Each service needs its own pipeline, logs, monitoring and alerts. Tracing a single customer's request across five services needs tooling.

A well-organised single application, often called a modular monolith, gives many of the design benefits without these costs. Microservices pay off mainly when many teams are blocked by releasing together.

The shortcut

Before splitting, ask "Is our pain about teams, or about code?" Tangled code is fixed with better modules. Teams blocking each other's releases is the pain microservices solve. Then split one capability at a time, starting with the one whose edges are clearest.

The trap is the distributed monolith: services that share one database or must be deployed together. You pay every cost of microservices and get none of the independence.

Drills

Answer fast — trust the rule.

Remember

• One team, one service, one database, one deploy button.
• Shortcut: "is our pain about teams, or about code?" Then split one capability at a time.
• Trap: the distributed monolith, with shared databases or deploys that must happen together.