Microservices Architecture

Cover this or you fail the question

• An application built as a set of small, independently deployable services, each responsible for one business capability and communicating over a network rather than through in-process calls.
• Independent deployability is the defining property. If two services must be released together, they are one service in two repositories, and none of the benefits apply while all of the costs do.
• Services are organised around business capabilities — ordering, payments, inventory — rather than technical layers. A 'database service' and a 'UI service' is a layered monolith split across a network, which is the worst of both.

Cover this or you fail the question

• Single responsibility: a service does one thing, and its boundary follows a business capability that a team can own end to end.
• Loose coupling: services interact through a stable published interface and know nothing of each other's internals, so one can be rewritten without coordinating with its callers.
• Decentralised data: each service owns its own datastore and no other service reads it directly. This is the principle most often violated and the violation that hurts most, because a shared database recreates tight coupling invisibly — a schema change now breaks services whose code never referenced it.
• High cohesion: things that change together live together. A boundary that forces most changes to touch three services is drawn in the wrong place, and the frequency of cross-service changes is the practical test of whether the boundaries are right.

Common trap: Describing services that share one database. It is the single most common wrong answer here, and interviewers ask about data ownership specifically to find it.

What separates a solid answer

• Synchronous request-response is simple and immediate, and it couples availability: if a call to another service is required to answer a request, the caller is only as available as everything it depends on, and a chain of five such calls compounds.
• Asynchronous messaging decouples availability and smooths load, at the cost of eventual consistency and a system that is harder to follow, because there is no single call stack describing what happened.
• The useful heuristic is that a caller needing an answer to complete its own response is synchronous, while telling other parts of the system that something happened is asynchronous. Emitting an event and letting interested services react is what keeps a service from needing to know who cares.
• Interfaces must evolve compatibly, since you cannot deploy every consumer at once. Additive changes are safe; removing or renaming a field is a coordinated migration whether it is planned as one or not.

What separates a solid answer

• Every network call has failure modes a function call does not: it can be slow, fail, or succeed without the caller learning that it did. The last case is why operations that may be retried need to be idempotent, or a retried payment charges twice.
• Timeouts are mandatory and must be shorter as you go deeper in a call chain, or an outer request waits on an inner one that has already given up.
• A circuit breaker stops sending requests to a dependency that is failing, which protects the failing service from being kept down by retries and lets the caller degrade quickly instead of consuming its own capacity waiting.
• Graceful degradation should be specified per dependency, since it is a product decision rather than a technical one: if the recommendations service is down, showing a generic list is usually far better than failing the page.
• Retries need backoff and jitter. Synchronised retries from many callers turn a brief blip into a sustained overload, and this is one of the most common self-inflicted outages in a distributed system.

The senior signal

• A transaction spanning services is not available in the way it is within one database, and this is the hardest genuine consequence of the architecture rather than a detail.
• The saga pattern is the standard response: a sequence of local transactions, each with a compensating action that undoes it if a later step fails. Compensation is a business decision — the reverse of shipping an order is not deleting a row, it is a return process.
• Between steps the system is in an intermediate state that is visible, so the product has to define what a user sees during it. Pretending the window does not exist is where designs fail in practice.
• The transactional outbox solves the dual-write problem: writing to the database and publishing an event are not atomic, so the event is written to the same database in the same transaction and published from there. Without this, a service can commit a change and never tell anyone, which produces divergence that is extremely difficult to diagnose later.

The senior signal

• Debugging spans services, so distributed tracing with a request identifier propagated across every hop stops being optional. Without it, an investigation means correlating timestamps across several log streams by hand.
• Every service needs a deployment pipeline, monitoring, alerting, on-call ownership and dependency upkeep. Multiplying that by forty services is a platform team's worth of work, and pretending otherwise is how organisations end up with services nobody maintains.
• The strongest senior point is about motivation: microservices are primarily a solution to organisational scale, letting many teams ship without contending in one codebase and one release. If there are three engineers, that problem does not exist and the costs are paid for nothing.
• The pragmatic recommendation is to start with a well-structured monolith with clear internal module boundaries, and extract a service when there is a specific reason — a component with a very different scaling profile, a different availability requirement, or a team blocked by contention. Extracting along boundaries already proven inside the monolith is far more likely to produce the right ones than designing them upfront.