What are Microservices?
Microservices architecture breaks applications into small, independent services that communicate over well-defined APIs. Each service owns its data and can be developed, deployed, and scaled independently.
Benefits of Microservices
- Independent deployment and scaling
- Technology diversity (use best tool for each service)
- Fault isolation (one service failure doesn't bring down entire system)
- Team autonomy
Challenges
- Increased complexity in communication
- Data consistency across services
- Network latency
- Service discovery and configuration
Service Communication
Services can communicate via:
- Synchronous: REST, gRPC (request-response)
- Asynchronous: Message queues, event streaming (Kafka, RabbitMQ)
API Gateway Pattern
An API gateway acts as a single entry point, handling routing, authentication, rate limiting, and request aggregation.
Data Ownership and Reliability
Each service should own its data and expose changes through an API or event rather than allowing other services to query its tables directly. Cross-service workflows often use events, sagas, and compensating actions because a single database transaction cannot safely span independent services. Consumers must be idempotent, messages need durable delivery, and teams should plan for duplicates, delays, and out-of-order events.
Operational maturity is a prerequisite for microservices. Use timeouts, bounded retries with backoff, circuit breakers, health checks, distributed tracing, and correlation identifiers. Define service-level indicators for latency, errors, and availability, and make deployments backward compatible so services can evolve independently. A modular monolith is usually a better starting point when team boundaries and scaling needs are still unclear; extract a service only when the ownership or operational benefit outweighs the distributed-systems cost.
Next Steps
Microservices are powerful but require careful design. Put the building blocks together in the complete URL shortener system design case study.
A Practical Mental Model for Microservices Architecture
Microservices split a product into independently deployable services with explicit ownership of behavior and data. The definition matters, but the more useful skill is connecting it to a user-visible goal and a measurable operating limit. A design is convincing when it explains what improves, what becomes more complex, and what evidence would trigger the next change.
The useful boundary follows a business capability and team ownership, not an arbitrary technical layer. Services communicate through versioned APIs or events and must tolerate partial failure because a local call has become a network call. Draw the critical request path first. For every hop, name the work performed, the state read or changed, and the way that hop can fail. This prevents a diagram full of boxes from hiding the actual behavior.
A simple way to reason about microservices architecture is to separate four concerns: correctness, performance, availability, and operability. Correctness protects user and business invariants. Performance defines latency and capacity. Availability describes degradation during failure. Operability covers deployment, observation, recovery, and cost. Improving one concern can make another harder, so every design choice needs a stated priority.
Worked Example and Capacity Reasoning
An order workflow can separate checkout, payment, inventory, and fulfillment only when each capability has clear ownership. The checkout service creates a pending order, publishes an event through a transactional outbox, and a saga coordinates compensation if payment succeeds but inventory reservation fails.
Turn the narrative into numbers before selecting infrastructure. Estimate average and peak request rates, the read-to-write ratio, payload size, retained data, and acceptable response time. Add headroom for traffic bursts and failures, but show the arithmetic. The goal is not a perfect forecast; it is to distinguish a design that needs one machine from one that needs partitioning, replication, or asynchronous processing.
Next, trace one successful request and one failed request. The successful trace validates the normal data flow. The failed trace forces decisions about timeouts, retries, idempotency, stale data, and user feedback. If the system can only be explained while every dependency is healthy, the design is incomplete.
Design Decisions to Make Explicit
Begin with a modular monolith unless independent scaling, release cadence, or organizational ownership justifies distribution. In production, validate this with a small experiment or load test, then expose a metric and an alert that show whether the decision still holds. In an interview, state the trade-off plainly instead of presenting the choice as universally correct.
Give each service authority over its data and expose behavior instead of allowing cross-service table access. In production, validate this with a small experiment or load test, then expose a metric and an alert that show whether the decision still holds. In an interview, state the trade-off plainly instead of presenting the choice as universally correct.
Use synchronous calls for immediate answers and events for decoupling, buffering, and fan-out. In production, validate this with a small experiment or load test, then expose a metric and an alert that show whether the decision still holds. In an interview, state the trade-off plainly instead of presenting the choice as universally correct.
Design idempotency, tracing, timeouts, retries, and schema evolution before traffic depends on the service boundary. In production, validate this with a small experiment or load test, then expose a metric and an alert that show whether the decision still holds. In an interview, state the trade-off plainly instead of presenting the choice as universally correct.
These decisions should appear next to the component they affect. A short annotation such as “p99 under 250 ms,” “eventual consistency under 30 seconds,” or “survives one availability-zone failure” makes the diagram testable. Without a target, terms such as fast, scalable, and highly available are only aspirations.
Common Failure Modes
- 1. A distributed monolith requires many services to deploy together and combines network risk with tight coupling. For Microservices Architecture, document the expected behavior, the capacity assumption behind it, and the fallback when that assumption stops being true.
- 2. Retrying non-idempotent commands creates duplicate payments, messages, or orders. For Microservices Architecture, document the expected behavior, the capacity assumption behind it, and the fallback when that assumption stops being true.
- 3. Long synchronous call chains multiply latency and availability risk. For Microservices Architecture, document the expected behavior, the capacity assumption behind it, and the fallback when that assumption stops being true.
- 4. Shared databases let one service bypass another service’s invariants. For Microservices Architecture, document the expected behavior, the capacity assumption behind it, and the fallback when that assumption stops being true.
Do not try to eliminate every failure. Decide which failures must be masked, which can produce a degraded response, and which should reject new work quickly. Bounded queues, deadlines, bulkheads, and circuit breakers are often safer than unlimited retries. Recovery also needs verification: regularly test restores, failovers, rebalancing, and rollback paths before an incident makes them necessary.
Observability and Production Readiness
At minimum, monitor end-to-end trace duration, dependency error rate, event lag and dead letters, deployment and rollback frequency. Break metrics down by endpoint, dependency, region, or partition where an aggregate could conceal a hotspot. Pair metrics with structured logs for local detail and distributed traces for request paths that cross service boundaries.
Alerts should describe user impact or exhausted safety margin, not every small fluctuation. Use service-level objectives to connect telemetry to a promise: for example, 99.9% of valid requests succeed and 99% finish within the target latency over a rolling window. Add dashboards for traffic, errors, duration, saturation, and deployment markers so an operator can see whether a regression began with load, a dependency, or a release.
Capacity planning is continuous. Record the tested limit, current peak, growth rate, and time required to add capacity. If the system needs thirty minutes to scale safely, an alert at ninety-nine percent utilization is too late. Operational readiness is part of system design because a component that cannot be observed or recovered is not dependable.
How to Explain This in a System Design Interview
- Clarify the requirement. Ask which user action depends on microservices architecture and define the success target.
- Estimate demand. Calculate peak traffic, data size, and the ratio that drives the design.
- Start simple. Present the smallest architecture that meets the current requirement before adding distributed machinery.
- Find the limit. Explain which resource or failure domain breaks first and how you know.
- Evolve the design. Add the next mechanism, then state its cost, consistency effect, and operational burden.
- Close with failure handling. Walk through one dependency failure and the metrics that reveal it.
This sequence demonstrates judgment. Interviewers usually care less about naming a particular product than about whether you can defend boundaries and adapt when a requirement changes. If a managed service is useful, describe the capability you need first, then mention the product as one implementation.
Review Checklist
- Is the functional scope clear, including what is deliberately excluded?
- Are peak traffic, storage, bandwidth, and latency targets quantified?
- Does every important write have an owner, durability rule, and idempotency strategy?
- Are consistency and staleness visible to the user explained?
- Can the design tolerate one instance, zone, or dependency failure as required?
- Are queues and retries bounded, and is overload rejected or degraded intentionally?
- Can an operator detect, diagnose, roll back, and recover the system?
- Is the next scaling step identified without paying for it prematurely?
Want a guided way to practice these trade-offs? Continue in System Design Fundamentals for Interviews on Udemy, which connects the concepts through complete interview case studies.
Continue Learning
Use the complete System Design interview-preparation guide to place this topic in a four-week roadmap. Then apply the same reasoning to the System Design case-study collection, where requirements, estimates, bottlenecks, and failure modes are combined in end-to-end designs.