Microservices split the system into small, deployable services, each owning a bounded domain (e.g. orders, users, notifications). Services communicate over the network (HTTP, gRPC, or messages). Benefits: teams can deploy independently, scale services separately, and use different tech per service. Trade-offs: operational complexity (many services to run, monitor, secure), network latency, and eventual consistency across services.

Design service boundaries around business capabilities and minimal coupling. Avoid chatty or circular calls.

Synchronous: caller waits for a response (HTTP, gRPC). Simple; but if the callee is slow or down, the caller blocks or fails. Use for: "need the result now" (e.g. get user profile, validate payment). Asynchronous: send a message and do not wait (queue, event). Caller continues; the other service processes later. Use for: "fire and forget" or "event happened" (e.g. send email, update analytics). Async improves resilience and decoupling but adds eventual consistency and operational complexity.

Mix both: sync for critical path, async for side effects and cross-cutting concerns.

An API gateway is a single entry point for clients. It routes requests to the right service (e.g. /users → user service, /orders → order service). It can do auth (validate JWT, API key), rate limiting, request/response transformation, and aggregation (BFF pattern). Clients talk to one host and port; the gateway hides the internal topology. Use when you have many services and want one place for cross-cutting concerns.

A service mesh (e.g. Istio, Linkerd) handles service-to-service traffic: mTLS, retries, timeouts, circuit breaking, and observability (metrics, tracing). It runs as a sidecar proxy next to each service; the service code does not change. Useful when you have many services and want consistent security and resilience without coding it in every service. Heavier to operate; adopt when the benefits (uniform policy, encryption, observability) justify the cost.