Interview Gauntlet: Monolith or Microservices?¶
Category: Architecture Trade-offs Difficulty: L2-L3 Duration: 15-20 minutes Domains: Architecture, Organizational Design
Round 1: The Opening¶
Interviewer: "You're starting a new project — an internal platform for managing employee onboarding workflows. The team is 6 engineers. Should you go with a monolith or microservices?"
Strong Answer:¶
"For 6 engineers building an internal tool, I'd start with a monolith. The reasoning: microservices solve organizational scaling problems — when you have 15 teams that need to deploy independently, microservices make sense because they decouple deployment schedules and team boundaries. With 6 engineers, you don't have that problem. You have one team, one deployment cadence, and one shared context. A monolith gives you simpler development (one codebase, one debugger, local function calls instead of network calls), simpler deployment (one artifact, one pipeline), simpler data management (one database, joins instead of cross-service queries), and simpler debugging (one set of logs, no distributed tracing needed). I'd structure the monolith with clear module boundaries — separate packages for user management, workflow engine, notifications, and document management — so that if we need to extract a service later, the boundaries are already defined. This is the 'modular monolith' approach."
Common Weak Answers:¶
- "Always microservices — they're more scalable." — Scalability isn't the bottleneck for an internal onboarding tool with probably 1,000 users. Premature microservices is one of the most expensive architectural mistakes.
- "Always monolith — microservices are overhyped." — Dogmatic in the other direction. The answer should depend on the context.
- "It depends." — True but empty without following up with the specific factors that determine the choice.
Round 2: The Probe¶
Interviewer: "Six months later, the platform is a success. Now it handles onboarding, offboarding, equipment management, and access provisioning. The team has grown to 20 engineers across 3 squads. When do you extract your first microservice, and which one?"
What the interviewer is testing: Understanding of when the pain of a monolith exceeds the cost of microservices, and how to identify service boundaries.
Strong Answer:¶
"I'd extract when I see one of three signals: deployment coupling (Squad A can't deploy their feature because Squad B's code broke the build), data model conflicts (two squads need the same table to have different schemas), or scaling mismatches (one module needs 10 instances to handle load while the rest need 2). The first extraction candidate should be the module with the clearest boundaries — meaning it has the least shared state with the rest of the monolith. For an onboarding platform, the notification service is often a good first extraction: it has a well-defined input (event + recipient + template), it doesn't share database tables with other modules (it has its own notification log and template store), and it has different scaling characteristics (it needs to handle burst sends without slowing down the main app). I'd extract it by: first, defining the API contract (probably an async event — publish to a message queue). Second, moving the notification code into a separate service that consumes from the queue. Third, running both in parallel (old and new) for a week to verify equivalence. Fourth, removing the old code from the monolith. The key: the monolith should call the new service through the same interface it used internally (an event/message), not through a synchronous HTTP call that tightly couples them."
Trap Alert:¶
If the candidate bluffs here: The interviewer will ask "How do you determine the boundary — specifically, how do you know if two modules share too much state to be cleanly separated?" The answer involves looking at database table access patterns: which modules read/write which tables. If two modules both do JOIN queries across the same tables, they're tightly coupled and hard to separate. If a module only accesses its own tables and communicates with other modules via function calls that could be replaced by events, it's a clean extraction candidate. Tools like code dependency analyzers or database access logs can help map this.
Round 3: The Constraint¶
Interviewer: "The CTO heard about your extraction plan and says: 'If we're going to microservices, let's go all in. Break the entire monolith into 8 services in this quarter.' React to that."
Strong Answer:¶
"I'd push back respectfully but firmly. Extracting all 8 modules simultaneously is a high-risk, high-cost approach that's likely to fail for several reasons. First, the 'big bang' rewrite is one of the most well-documented anti-patterns in software engineering. We'd be simultaneously debugging 8 new service boundaries, 8 new deployment pipelines, distributed transactions, and cross-service communication — while also trying to deliver features. Second, we'd need infrastructure we don't have yet: a service mesh or API gateway for routing, distributed tracing for debugging cross-service issues, a message broker for async communication, and CI/CD pipelines for 8 separate services. Building this infrastructure is a quarter of work by itself. Third, we don't know which service boundaries are correct yet. Extracting incrementally lets us validate each boundary with real usage. If we extract all 8 and discover that services C and D actually share so much state that they should be one service, we've done unnecessary work and added unnecessary network hops. My counter-proposal: extract 1-2 services this quarter, starting with the clearest boundaries. Use that experience to build the shared infrastructure (CI/CD templates, observability, service communication patterns). Then extract 2-3 more next quarter with battle-tested patterns. Full extraction in 3 quarters instead of 1, with much lower risk."
The Senior Signal:¶
What separates a senior answer: The organizational and political skill to push back on a CTO's directive with a constructive counter-proposal. Technical leaders often face pressure to adopt sweeping changes. The senior response is not "you're wrong" but "here's a plan that achieves the same goal with less risk." Also: citing the infrastructure prerequisites (observability, messaging, CI/CD) that microservices require — these are often forgotten in the enthusiasm for decomposition.
Round 4: The Curveball¶
Interviewer: "Conway's Law says your architecture mirrors your org structure. Your 3 squads are organized by function: frontend, backend, and infrastructure. Should you reorganize the teams around services?"
Strong Answer:¶
"Conway's Law is an observation, not a recommendation — but the reverse Conway maneuver (intentionally structuring teams to produce the architecture you want) is a powerful tool. Currently, the frontend/backend/infrastructure split means every feature requires coordination across all three teams. This is inefficient for microservices because no single team owns a service end-to-end. For a microservice architecture, I'd recommend reorganizing into domain-aligned squads: an Onboarding squad that owns the onboarding service (frontend, backend, and infrastructure), an Access Provisioning squad that owns access management, and a Platform squad that owns shared infrastructure (CI/CD, observability, shared libraries). Each domain squad can develop, deploy, and operate their service independently. But — and this is the important caveat — this reorganization only makes sense if the services actually exist as independent units. If we're still a monolith with aspirations of microservices, reorganizing teams first creates confusion because no one can work independently yet. My preference: extract the first 2-3 services, then reorganize teams to own them. Structure follows strategy follows architecture."
Trap Question Variant:¶
The right answer is "it depends on timing." Candidates who say "always reorganize first" are applying theory without considering the current state. Candidates who say "never reorganize" are ignoring the real organizational dynamics that make microservices work or fail. The insight is that team structure and service architecture need to co-evolve, and the order matters: don't reorganize teams around services that don't exist yet.
Round 5: The Synthesis¶
Interviewer: "A junior engineer asks you: 'When should I choose microservices?' Give them a heuristic they can use."
Strong Answer:¶
"Choose microservices when the pain of coordination exceeds the pain of distribution. Specifically: consider microservices when you have multiple teams that need to deploy at different cadences, when parts of your system have dramatically different scaling requirements, or when you need to use different technology stacks for different components (e.g., one module needs Python for ML and another needs Go for performance). But here's the key test: if you can't deploy your monolith multiple times per day without breaking things, microservices won't fix that — they'll make it worse, because now you have 8 things you can't deploy reliably instead of 1. The prerequisites for successful microservices are: solid CI/CD (automated tests, automated deployment), observability (centralized logging, metrics, tracing), and operational maturity (on-call, incident response, runbooks). If you don't have these for a monolith, add them first. They're easier to build for a monolith and they transfer directly when you decompose later. The heuristic: monolith until the team organization or deployment cadence forces your hand, then extract services at the seams where coordination pain is highest."
What This Sequence Tested:¶
| Round | Skill Tested |
|---|---|
| 1 | Context-appropriate architecture selection |
| 2 | Service boundary identification and extraction strategy |
| 3 | Stakeholder management and incremental migration planning |
| 4 | Organizational design awareness (Conway's Law in practice) |
| 5 | Ability to distill complex trade-offs into actionable heuristics |