Microservices Architecture and Service Decomposition Questions

Direct answer
When a cross-functional team is split on microservices versus a modular monolith, the way through is to replace the debate with data: define the two or three signals that would actually decide it (current deploy coordination cost, whether any component needs independent scaling, and team-ownership friction), measure them on the real system, and let the measured answer, not the strongest opinion in the room, drive the recommendation.

Structured elaboration
A workable process looks like this: first, separate the technical disagreement from the underlying interests, since "microservices vs. modular monolith" arguments are often proxies for real but unstated concerns (a team wanting more autonomy over its release schedule, or an SRE team worried about operational load from more moving parts); surfacing those interests directly is usually more productive than debating architecture in the abstract. Second, agree on what evidence would settle the disagreement before gathering it, for example current deploy-queue wait times, incident data showing whether failures are concentrated in a few components, and headcount growth projections for the next year, so the data collection isn't retroactively interpreted to fit whichever side is winning the argument. Third, run a small, time-boxed spike, such as extracting one candidate module behind a clean interface first inside the monolith, to surface real integration costs before committing to a full split. Finally, make the recommendation with an explicit, falsifiable success measure attached (for example, "deploy frequency for the extracted service should double within two quarters, or we roll the decision back"), so the decision doesn't become permanent by default just because it shipped.

Worked example
A concrete facilitation sequence: run a short workshop where each side states the specific outcome they're worried about (not the architecture they prefer), collect the deploy-cadence and incident data for the modules under debate, and present both sides with the same evidence before asking for a recommendation, rather than presenting a pre-formed conclusion and asking for buy-in. If the data shows one module already has a measurably different release cadence and on-call profile from the rest, that's the concrete justification for extracting just that module, which often resolves the broader disagreement by making the actual scope much smaller than "microservices vs. modular monolith" implied.

Trade-offs and pitfalls
The most common failure in this kind of facilitation is letting the loudest technical opinion win instead of the data, which produces a decision the losing side doesn't actually buy into and will relitigate at the next disagreement. The second common failure is presenting the recommendation as a permanent, unreviewable architectural commitment rather than attaching a measurable checkpoint; when the plan includes an explicit point to check whether the split delivered what it promised, disagreement about the initial decision matters much less because everyone knows it will be revisited with evidence.

Direct answer
A monolith is a single deployable unit that contains all of an application's functionality and typically talks to one shared database. A microservices architecture splits that functionality into a set of independently deployable services, each owning its own data and communicating with the others over the network (HTTP, gRPC, or messaging). The core trade-off is operational and organizational complexity (many moving parts, network calls where there used to be function calls) traded for independent deployability and independent scaling of each piece.

Structured elaboration
Four dimensions decide which style fits a given system:

• Deployability: in a monolith, every release ships the whole application together, so a one-line change and a schema migration go out in the same deploy. In microservices, each service ships on its own schedule, but that independence only pays off once you also have per-service CI/CD, versioned contracts between services, and a way to test one service's change without spinning up the whole system.
• Team scaling: a monolith lets a handful of engineers move fast because there is one codebase and one deploy pipeline to reason about. As the team grows past roughly 20-30 engineers, a shared codebase and shared release train start to produce merge contention and "who owns this file" ambiguity; independently-owned services give each team a boundary to work inside without coordinating every change with everyone else.
• Scaling the system: a monolith scales by running more copies of the whole application, even if only one code path (say, search) is actually hot. Microservices let you scale the hot path's service independently, at the cost of running and monitoring more separate processes.
• Operational overhead: a monolith has one thing to deploy, log into, and page on-call for. Microservices multiply that by the number of services: more deployment pipelines, more inter-service contracts to keep backward-compatible, more places a request can fail partway through, and a genuinely different debugging experience (a single stack trace becomes a distributed trace across several services).

Worked example
A payments feature that reconciles overnight batches for one company and needs to add a new reconciliation rule once a quarter is a poor fit for microservices: the team is small, the release cadence is low, and there is no independent-scaling need, so a monolith (or a module inside one) minimizes operational overhead for the actual rate of change. A checkout system at a retailer during a high-traffic sale, by contrast, needs to scale the payment-authorization path independently of the product-catalog browsing path, and different teams own each; that combination of an independent-scaling need and independent-team-ownership need is what makes the added operational cost of a separate service worth paying.

Trade-offs and pitfalls
The most common mistake is treating microservices as inherently "better" architecture rather than a trade of operational complexity for independent deployability and scaling. A small team adopting microservices before it has the release cadence, team count, or scaling need to justify it typically pays the distributed-systems tax (network failures, harder debugging, contract versioning) without getting the corresponding benefit. The reverse mistake, staying monolithic well past the point where deployment coordination and scaling mismatch are actively slowing the team down, is just as real; the earlier answer about a modular monolith gives one commonly-used middle ground between the two.

Direct answer
A stateless approach (a signed token such as a JWT (JSON Web Token) carrying the session data) scales cleanly across many independently-deployed services and regions because any service instance can validate the token without needing to look anything up, at the cost of harder revocation and a token that, once issued, is difficult to invalidate before it naturally expires; a stateful approach (a shared session store, or sticky sessions at the load balancer) makes revocation and logout instantaneous, at the cost of needing that shared state to be available, fast, and consistent everywhere a request might land.

Structured elaboration
Security and revocation: a self-contained signed token is valid until it expires, no matter what happens on the server side, so immediate logout or a forced revocation (say, after a password change or a detected compromise) is hard to achieve without an additional mechanism, like a short token lifetime combined with a separate, checked-on-every-request revocation list (which reintroduces some of the shared-state lookup a stateless token was meant to avoid). A server-side session store makes logout and revocation trivial (just delete or invalidate the session record), since every service checks the current, authoritative state on each request. Session size and load balancing: a stateless token carries its own data on every request, so a large session payload adds overhead to every call and needs to stay reasonably small; sticky sessions route a given user consistently to the same backend instance holding their in-memory session, which avoids a shared store but makes load balancing less flexible (that instance failing loses the session, and rebalancing traffic away from a hot instance is constrained by which users are stuck to it) and doesn't scale cleanly across regions, since a user's session is now tied to a specific instance's location.

Worked example
For a web application serving 10M monthly active users across multiple regions, a stateless token is generally the better fit for the base authentication case, since it avoids needing a globally-consistent, low-latency session store that every region's services can reach quickly; the revocation gap is managed by keeping token lifetimes short (minutes to a couple of hours) and using refresh tokens (which ARE checked against a server-side store on each refresh) to balance the low-friction stateless validation for most requests against the ability to revoke access within a bounded, acceptable window. A legacy component that genuinely requires sticky sessions during a migration can be bridged with an adapter: a thin layer that translates the stateless token into whatever session format the legacy component expects, or a temporary session-affinity rule scoped only to that component's traffic, while the rest of the system moves to the fully stateless model.

Trade-offs and pitfalls
The common mistake with stateless tokens is putting too much or too sensitive data directly in the token (since anyone who can decode it, even without the signing key, can read its contents unless it's also encrypted), and underestimating how long a compromised token stays valid if the revocation story isn't designed deliberately. The common mistake with sticky sessions is treating them as a permanent architecture rather than what they usually are in a modern system, a legacy bridge or a stopgap, since they fundamentally limit how flexibly you can load-balance, fail over, and scale across regions compared to a genuinely stateless design.

Direct answer
The strangler fig pattern migrates a monolith to microservices incrementally: you place a routing layer in front of the monolith, redirect one slice of functionality at a time to a newly-built service behind that layer, and let the monolith's role shrink slice by slice until, eventually, it can be retired, rather than attempting a single big-bang rewrite.

Structured elaboration
The routing (or intercept) layer is the mechanism that makes this incremental: it sits in front of the monolith and inspects each incoming request, forwarding requests for the not-yet-migrated functionality to the monolith as before, and requests for the newly-extracted slice to the new service instead. Because the routing decision happens per-request, the cutover for any one slice can be gradual (a percentage of traffic, or a specific subset of users) and reversible (route back to the monolith if the new service misbehaves), rather than an all-at-once switch.

An anti-corruption layer handles the case where the new service still needs to talk to the old monolith, either because the monolith still owns some data the new service needs, or because other parts of the monolith still call into the functionality that's now been extracted. Rather than letting the new service's clean domain model get contaminated by the monolith's legacy data shapes and conventions, the anti-corruption layer translates between the two, so the new service's internal model stays coherent even while it's still dependent on the old system underneath.

Managing shared database access during migration is the trickiest part: in the transition window, both the monolith and the new service may need to read or write data that hasn't fully moved yet. A common approach is dual-write (the monolith continues writing to its tables while also publishing changes the new service consumes) with reconciliation to catch drift, or a change-data-capture stream from the monolith's database that the new service consumes without writing to the monolith's tables directly, avoiding a genuine two-way dependency on the same schema.

Worked example
Prioritizing which components to extract first: start with a slice that's relatively self-contained (few dependencies on the rest of the monolith), has a clear owning team ready to take it on, and delivers a visible win (either operational, like removing a frequent source of incidents, or business, like unblocking a team that's currently release-blocked by the monolith's shared deploy train). Extracting the riskiest, most deeply-entangled part of the monolith first, even if it's the part causing the most pain, tends to produce the highest-risk first migration when the team has the least experience running this pattern; a smaller early win builds the operational muscle (routing, dual-write, monitoring the new service) that the harder extractions will need later.

Trade-offs and pitfalls
The most common failure is leaving the routing layer and the dual-write/reconciliation logic in place indefinitely instead of treating them as temporary migration scaffolding; if a slice never gets fully cut over (the monolith keeps a code path alive "just in case"), the system ends up permanently carrying the complexity of both the old and new implementations, which is worse than either the original monolith or a clean microservice on its own.

Direct answer
Behavioral answer skeleton: describe a specific decomposition decision made (the boundaries chosen and why), what actually happened once it shipped (either it didn't go as planned, or it delivered a measurable improvement), and what that outcome revealed, whether a lesson learned from a setback or concrete evidence the decision was right.

Structured elaboration
A strong version of this story names the actual boundary decision (which service was split from what, and the reasoning at the time), not just "we adopted microservices." For the setback version: what specifically didn't go as planned (a boundary that turned out to force more cross-service coordination than expected, or a scaling assumption that didn't hold), how it was diagnosed (what signal first revealed the problem, whether an incident, a slow release cadence, or direct team feedback), and the concrete fix or the lesson carried forward (a corrected boundary, a new team-ownership model, or a changed process for validating boundaries before committing to them next time). For the success version: what was measured to confirm the decomposition actually delivered value, whether an increase in independent deploy frequency for the extracted service, a drop in incidents caused by unrelated changes to a previously-shared service, or a faster mean-time-to-recovery once the failure domain was smaller.

Worked example
A representative setback story: a service was split expecting two teams to be able to work independently, but the boundary was drawn along a technical line (splitting a read path from a write path) rather than a business-domain line, and the two resulting services turned out to need frequent, tightly-coordinated releases anyway because a business rule change usually touched both. The signal that revealed this was release velocity not improving the way the split was supposed to deliver, and cross-team coordination overhead showing up in retrospectives. The fix was re-drawing the boundary along the actual business domain instead of the technical read/write line, after which the two teams could genuinely release independently. A representative success story: extracting a reporting service from a shared order-processing service, after which order-processing's deploy frequency roughly doubled (no longer blocked by reporting's separate, slower release cycle) and a subsequent reporting-specific incident had zero impact on order processing, which was the exact goal the extraction was measured against.

Trade-offs and pitfalls
A weak answer to this question stays vague about what actually went wrong or right ("the migration was challenging but we got through it") without naming the specific boundary decision, the specific signal that revealed the outcome, or a specific number or concrete change that resulted; interviewers are listening for evidence the candidate can reason critically about their own past decomposition decisions, not just narrate that a project happened.