Services and microservices

Monolith

One artifact, one deployment, one runtime. Internal calls are method calls.

Pros: single deployable, no network between modules. Cons: long release cycle, scales only as a whole, hard to split across teams.

graph LR C[Clients] --> G[API Gateway] G --> B[Book service] G --> R[Review service] B --> BD[(Book DB)] R --> RD[(Review DB)]

Each service is developed, deployed, scaled and upgraded separately and may own its own database.

A structure is stable when it is loosely coupled and highly cohesive.

Loose coupling - services talk over an API; a change inside one does not force a change in another.
High cohesion - one service owns exactly one piece of data.

Factor	In practice
Config	configuration comes from the environment, not from the image
Processes	stateless; state goes to a backing service or a volume
Disposability	fast start-up, graceful shutdown on SIGTERM
Logs	write to stdout/stderr, never to a file inside the container

An application that breaks these will fight you in Kubernetes all week: it will not survive a rescheduled Pod, a rolling update, or kubectl logs.