Copy<\/button><\/div>\n\nlivenessProbe:\n\n httpGet:\n\n path: \/healthz\/live\n\n port: 8080\n\n periodSeconds: 10\n\n failureThreshold: 3\n\nreadinessProbe:\n\n httpGet:\n\n path: \/healthz\/ready\n\n port: 8080\n\n periodSeconds: 5\n\n failureThreshold: 2\n<\/code><\/pre><\/div>Why does 'database per service' matter, and what do you give up by enforcing it?<\/span>Data Management<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Each service owning its own database, with no other service allowed to query it directly, is what actually makes services independently deployable. Without it, a schema change in one service can silently break another service’s queries, and you’ve got a distributed system with a monolith’s coupling hiding inside it.<\/p>\n
What you give up is the easy JOIN. Any question that spans two services’ data now needs an API call, an aggregation layer, or a data pipeline instead of one SQL query, and that trade-off is the real cost of the pattern, not a footnote.<\/p>\n
<\/div><\/div><\/div>\n
Why is a single request ID enough in a monolith but not enough across microservices?<\/span>Observability<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
In a monolith, one request ID tags one process’s logs, and that’s the whole picture. Across microservices, a single user action can fan out into calls to five or ten services, each logging independently, so a trace ID needs to travel along on every downstream call and show up in every one of those services’ logs to reconstruct the full picture.<\/p>\n
Without that propagated trace ID, debugging turns into grepping five different log systems by timestamp and hoping the timing lines up, which under load, it often doesn’t.<\/p>\n
<\/div><\/div><\/div>\n
What's OpenTelemetry, and why has it mostly replaced vendor-specific tracing SDKs?<\/span>Observability<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
OpenTelemetry (OTel) is a vendor-neutral standard for generating traces, metrics, and logs, one SDK and one wire format that every backend, Jaeger, Datadog, Honeycomb, whatever your company picks next year, can ingest, instead of instrumenting your code against one vendor’s proprietary agent and having to re-instrument everything if you switch tools.<\/p>\n
Before OTel, switching observability vendors meant ripping out instrumentation code across every service and rewriting it against the new vendor’s SDK, which is exactly the kind of lock-in cost that made teams stay on a tool they’d outgrown. Now the instrumentation stays put and only the export destination changes, which is a bigger deal for a company’s actual flexibility than it sounds on a whiteboard.<\/p>\n
<\/div><\/div><\/div>\n
What does it mean for a microservice to be stateless, and what do you actually do when a service needs to remember something between requests?<\/span>Statelessness<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
Stateless means the process itself doesn’t hold onto anything specific to a request once it’s done responding. No request-specific data sitting in local memory, no in-process session object tied to one user. Because of that, any instance of the service can pick up any incoming request, and you can kill an instance, spin up a new one, or scale from three pods to thirty without losing anything a user cares about. That’s the whole point: it’s what makes horizontal scaling and rolling restarts safe.<\/p>\n
The catch is that real systems do need to remember things, a shopping cart, a login session, a multi-step checkout flow. The answer is you push that state somewhere external to the process: a Redis cache keyed by user or session ID, a database row, or a signed token like a JWT that the client carries and sends back on every request so the server doesn’t have to store anything at all. A cart service, for example, shouldn’t keep the cart in a local hash map, it should write it to Redis on every update so it survives a pod restart and any instance can serve the next request for that user.<\/p>\n
The workaround teams sometimes reach for instead is sticky sessions, pinning a user to one specific instance at the load balancer. It works, but it quietly undoes the benefit you split services for in the first place. Now that one instance can’t be drained or scaled down without dropping active sessions, and your load balancer has to track affinity instead of just spreading load evenly. It’s a crutch, not a fix.<\/p>\n
<\/div><\/div><\/div>\n
What's the risk of sharing a common code library across all your microservices?<\/span>Shared libraries<\/span>Easy<\/span><\/span><\/span><\/button><\/p>\n
It quietly rebuilds the monolith you were trying to get away from, just at the dependency level instead of the deployment level. If every service pulls in the same internal library for, say, order validation logic or a shared “User” model, then a change to that library doesn’t just affect one team, it obligates every service that depends on it to eventually rebuild and redeploy. You’ve traded a single deployable artifact for a dozen services that all have to move in lockstep whenever that shared code changes, which is most of the coordination cost you split the monolith to avoid.<\/p>\n
The more concrete failure mode is version skew. Team A bumps the shared library to pick up a bug fix and redeploys. Team B is mid-sprint and doesn’t. Now you’ve got two services in production serializing the same “domain” object slightly differently, or applying business rules that diverged the moment one side updated and the other didn’t. These bugs are nasty because nothing crashes, you just get quietly wrong behavior at the boundary between two services that both think they’re using the same code.<\/p>\n
The practical line most teams draw is: share generic, infrastructure-level code, things like a logging wrapper, a standard HTTP client with retry and tracing headers baked in, or auth token parsing. Don’t share domain models or business logic across service boundaries, that’s exactly the coupling that bounded contexts exist to prevent. If two services need the same domain concept, that’s usually a sign they shouldn’t have been split in the first place, or that one of them needs to own that concept and expose it through an API instead of a shared class.<\/p>\n
<\/div><\/div><\/div>\n
<\/span>Medium questions<\/h2>28<\/span><\/div><\/div><\/div>\n
When does splitting a monolith into microservices actually pay off, versus just adding operational overhead?<\/span>Architecture Trade-offs<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
It pays off when different parts of the system need to scale independently, are owned by different teams who’d otherwise block each other on deploys, or carry genuinely different reliability requirements. It adds overhead, and mostly just overhead, when a small team splits a low-traffic app into a dozen services because that’s what big companies do.<\/p>\n
The tell interviewers look for: can you name a concrete scaling or ownership problem the split solves, or are you just repeating the Netflix justification. The “start with a monolith and split once boundaries are understood from real usage” argument comes up often enough to be worth having a position on.<\/p>\n
<\/div><\/div><\/div>\n
How do you decide where one microservice ends and another begins?<\/span>Service Boundaries<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Draw the line around a business capability that changes for its own reasons, not around a technical layer. Orders, payments, and inventory usually end up as separate services because they change on separate release schedules and are owned by separate teams; splitting “read” and “write” into different services rarely reflects a real boundary on its own.<\/p>\n
Weak answers describe boundaries by data model or by technology (“one service per team’s favorite framework”). Interviewers want you reasoning from business change frequency and ownership, the two things that actually predict whether a boundary holds up a year later.<\/p>\n
<\/div><\/div><\/div>\n
What's a bounded context, and why does it matter when drawing service boundaries?<\/span>Domain-Driven Design<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
A bounded context is a boundary within which a specific domain model and its vocabulary stay consistent. The word “order” inside the fulfillment service can mean something subtly different than “order” inside the billing service, and that’s fine as long as each context defines its own meaning clearly.<\/p>\n
It matters because forcing one shared Order object across every service is one of the more common causes of tight coupling in a system that’s supposed to be loosely coupled. Each service should own its own model of a concept, translating at the boundary through an API contract, instead of sharing a single canonical class across service lines.<\/p>\n
<\/div><\/div><\/div>\n
What's the strangler fig pattern, and why do most real-world migrations use it instead of a full rewrite?<\/span>Migration Strategy<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
The strangler fig pattern routes traffic for one specific capability, say the returns workflow, to a new microservice while everything else keeps hitting the old monolith through a facade or reverse proxy. Over months, more capabilities get carved out and rerouted until the monolith has nothing left to do and gets switched off, rather than every team stopping feature work for a year to rewrite from scratch.<\/p>\n
The proxy layer is the part interviewers actually want you to describe, since routing has to be correct at the URL or feature level from day one, otherwise a customer bounces between old and new systems mid-session and sees stale data on one side. I’ve watched a migration stall for eight months because nobody had clearly owned that routing layer, not because carving out the first service was hard.<\/p>\n
<\/div><\/div><\/div>\n
What's Conway's Law, and how does it actually change how you draw service boundaries?<\/span>Team Topology<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Conway’s Law says a system’s architecture ends up mirroring the communication structure of the organization that builds it. If two teams sit in separate reporting lines and rarely talk, the software boundary between their pieces hardens along that same line, whether or not it’s the right technical boundary.<\/p>\n
For microservices, this makes the org chart a design constraint, not a footnote. Teams sometimes draw a boundary that looks clean, then find six months in that two “separate” services need to change together on every release because one team owns both halves of a workflow split across the wrong seam. Reorganizing teams to match the boundary you actually want, the inverse Conway maneuver, is a real lever, not just a line people quote in a talk.<\/p>\n
<\/div><\/div><\/div>\n
What's the real trade-off between synchronous and asynchronous communication in a microservices system?<\/span>Communication<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Synchronous calls (REST, gRPC) are simpler to reason about and give an immediate response, but they couple the caller’s availability to the callee’s: if the downstream service is slow or down, the caller is too, unless timeouts and fallbacks are built in. Asynchronous messaging decouples that availability at the cost of giving up an immediate answer and taking on eventual consistency.<\/p>\n
Interviewers push on this by asking you to pick a specific call in a specific flow, not the whole system, and defend it. “Everything should be async” is as wrong an answer as “everything should be sync.” A checkout confirmation page probably needs a synchronous inventory check; the email that follows doesn’t.<\/p>\n
<\/div><\/div><\/div>\n
What's an idempotency key, and why does a retried request need one?<\/span>Reliability<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
An idempotency key is a client-generated identifier attached to a request so that if the network drops the response and the client retries, the server recognizes “I’ve already processed this exact request” and returns the original result instead of, say, charging a customer twice.<\/p>\n
This matters because retries are unavoidable in a distributed system. Networks partition, pods restart mid-request, and load balancers occasionally route a retry to a different instance with no memory of the first attempt. Without an idempotency key, “just retry on failure” quietly becomes “sometimes double-charge on failure,” which is a much worse bug to explain to a customer.<\/p>\n
<\/div><\/div><\/div>\n
What's the risk of making everything event-driven instead of using a direct call?<\/span>Event-Driven Architecture<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Debuggability. A synchronous call chain shows up as one trace with a clear start and end. An event-driven flow scatters that logic across producers and consumers that never call each other directly, so tracing “why did this order never ship” means hunting through five services’ logs with no single request to follow.<\/p>\n
My honest take: teams that go all-in on events before they’ve built the tracing and dead-letter-queue tooling to support it usually regret it within a year. Events fit genuinely decoupled workflows, not every call that feels old-fashioned as a plain request.<\/p>\n
<\/div><\/div><\/div>\n
What problem does consumer-driven contract testing solve that end-to-end tests don't?<\/span>Contract Testing<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
Consumer-driven contract testing (Pact is the most common tool) lets a consuming service define, in code, exactly which fields and response shapes it depends on from a provider, then verifies the provider against that contract on every build, without either service standing up the other’s full stack. It catches a breaking change to a shared field the moment the provider team makes it, in their own CI pipeline, instead of three sprints later when a shared end-to-end environment finally gets deployed together.<\/p>\n
End-to-end tests still matter, but they’re slow, flaky across a dozen services, and tell you something broke without pointing at which contract. Contract tests are faster and narrower on purpose; they check the shape of an agreement, not the whole business flow.<\/p>\n
json<\/span>Copy<\/button><\/div>\n\n{\n\n \u201cconsumer\u201d: \u201ccheckout-service\u201d,\n\n \u201cprovider\u201d: \u201cinventory-service\u201d,\n\n \u201cinteractions\u201d: [\n\n {\n\n \u201cdescription\u201d: \u201cget stock for sku CHR-2291\u201d,\n\n \u201crequest\u201d: { \u201cmethod\u201d: \u201cGET\u201d, \u201cpath\u201d: \u201c\/inventory\/CHR-2291\u201d },\n\n \u201cresponse\u201d: {\n\n \u201cstatus\u201d: 200,\n\n \u201cbody\u201d: { \u201csku\u201d: \u201cCHR-2291\u201d, \u201cavailable\u201d: 42 }\n\n }\n\n }\n\n ]\n\n}\n<\/code><\/pre><\/div>What's a dead-letter queue actually for, and what should happen to a message that lands in one?<\/span>Event-Driven Architecture<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
A dead-letter queue (DLQ) catches messages that failed processing after the configured number of retries, so a poison message, one with a bug-triggering payload that will never succeed no matter how many times it’s retried, doesn’t block every other message stuck behind it in the same queue.<\/p>\n
The mistake teams make is treating the DLQ as a place messages go to disappear quietly. Someone needs to alert on DLQ depth and actually look at what landed there; otherwise a bug that’s been silently dropping every fifth order confirmation for two weeks doesn’t surface until a customer complains, and by then reprocessing means reconstructing state from logs instead of just replaying the queue.<\/p>\n
<\/div><\/div><\/div>\n
Kafka guarantees message ordering. True or false, and why does the honest answer matter for how you key your messages?<\/span>Message Ordering<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
False, or at least incomplete. Kafka only guarantees order within a single partition, not across an entire topic. Two events for the same order landing on different partitions can be processed out of order relative to each other, even though each partition individually stays strictly ordered.<\/p>\n
That’s why the partition key matters more than most candidates expect going in: keying by order ID sends every event for that one order to the same partition, preserving the order that actually matters, while spreading load across the topic’s other partitions for unrelated orders. Pick the wrong key, say a constant value, and you get perfect ordering with zero parallelism, which defeats the reason you picked Kafka in the first place.<\/p>\n
<\/div><\/div><\/div>\n
API gateway versus service mesh, what's the actual difference, and do you need both?<\/span>Service Mesh<\/span>Medium<\/span><\/span><\/span><\/button><\/p>\n
A gateway manages north-south traffic, requests coming into the system from outside. A service mesh (Istio, Linkerd) manages east-west traffic, service-to-service calls inside the cluster, adding retries, mutual TLS, and observability at the network layer through sidecar proxies instead of application code.<\/p>\n
Plenty of systems run both, and plenty run just a gateway for years before a mesh is worth the added complexity. The honest answer to “do you need a mesh” is usually not yet, not until you’ve got enough services that manually wiring retries and mTLS into each one has become its own maintenance burden.<\/p>\n
<\/div><\/div><\/div>\n
How does service discovery work when service instances scale up and down constantly?<\/span>Service Discovery<\/span>Medium<\/span><\/span><\/span><\/button>