Microservices Fundamentals

A distributed monolith is microservices that still deploy, fail, and scale together through shared databases, shared code, and synchronous call chains, giving you all the complexity of distribution with none of the independence.

The common microservices anti-patterns -- over-splitting, chatty services, god gateway, retry storms, shared-library coupling, and no ownership -- each reintroduce the pain microservices should remove, and each has a standard fix.

Monolith is simple but scales as one block; microservices scale and deploy independently but pay with network failure, eventual consistency, and operational complexity.

Gateway is the front door, Registry is the directory, Config Server is the rulebook, load balancer spreads traffic, each service owns its DB, Kafka and REST connect them, and monitoring plus circuit breakers keep it alive.

Gateway routes, Discovery finds, Circuit Breaker protects, Saga compensates, Event Sourcing logs, CQRS splits read/write, Strangler Fig migrates, DB-per-service isolates data, Sidecar helps, Bulkhead contains failure.

API Gateway is the single front door, Circuit Breaker fails fast to stop cascades, and Database-per-Service keeps each service's data private so services stay independent.

A request flows client to gateway to discovery to service to database, makes resilient inter-service calls when it needs another service's data, returns the response back through the gateway, and the whole journey is stitched together by a correlation identifier in structured logs and distributed traces.

Stop double charges with an idempotency key the server can recognize, a unique constraint on the transaction ID as the atomic last line of defense, and a single transaction that commits the charge and the key together.

Code rollback is easy; state rollback is not: once new data, events, or external side effects exist, the old binary cannot restore the old system, so reversibility must be designed in before you ship.

SOA is coarse-grained services on a central smart ESB sharing data under central governance; microservices are fine-grained, independently deployable services on lightweight protocols, each owning its own data under decentralized governance.

Senior answers prove the design is technically correct; staff and principal answers weigh whether the organization should pay the permanent cost in teams, platform, incident response, and years of evolution.

A shared database couples services through the schema no matter what the diagram says -- restore independence by giving each service sole ownership and routing cross-service access through APIs, events, replicated views, and reporting stores.