Interview prompt
Problem context
Skills being evaluated
Use the sequence below to surface constraints, choose boundaries, test failure behavior, and defend trade-offs. Concrete numbers are interview assumptions, not claims about a real production system.
Clarify the decision
- Identify which boundaries provide independent scale, failure, compliance, or delivery value and which are distributed modules in name only. Separate platform deficiencies from fundamentally wrong domain seams.
Establish scale assumptions
- Measure coordinated deploys, call depth, incident propagation, shared-table access, team cognitive load, cost, and change lead time. Compare by service cohort rather than declaring all microservices failed.
Functional and non-functional requirements
- Reduce operational and coordination cost, preserve valuable isolation, maintain customer availability, and give teams coherent ownership. The recovery must not repeat a flag-day rewrite.
High-level architecture
- Group services by cohesive domain and change coupling, create in-process modular boundaries, and consolidate low-value network hops into a deployable unit or cell. Retain edge services with true independent needs.
Data model and flow
- Replace synchronous internal calls with in-process interfaces during consolidation while preserving contract tests. Move shared data authority deliberately and retire duplicate events and caches.
Consistency and transaction boundaries
- Recombination can restore local transactions, but do not hide unresolved domain ownership in a larger database. Keep explicit modules and invariant owners.
Failure modes and recovery
- Route cohorts to the consolidated path, shadow outcomes, and keep old services read-only during rollback. Consolidation must not recreate one unbounded failure domain; use cells and internal bulkheads.
Security and privacy
- Preserve authentication and authorization boundaries within the process, review newly co-located data access, and remove obsolete service credentials and network exposure.
Observability and SLOs
- Track call elimination, lead time, coordinated deploys, incident rate, on-call load, cost, module dependency violations, and team satisfaction. Publish evidence without scoring teams.
Capacity and cost
- Fewer runtimes, networks, and replicas reduce cost, but consolidation may need larger failure-isolated cells. Optimize total operational cost, not container count alone.
Alternatives and trade-offs
- A distributed monolith has remote failure without autonomy; a modular deployable retains shared release but simpler operations. Keep services only where the independence is used.
Evolution and migration
- Pilot one highly coupled cohort, preserve APIs behind a facade, consolidate runtime and data, measure outcomes, then repeat. Retire obsolete platform automation as the fleet shrinks.
What Staff and Principal candidates should emphasize
- Distinguished candidates make reversal psychologically and politically possible through evidence and respect. They preserve useful boundaries, restore simplicity, and avoid swinging to one giant unmodular process.
Decision trade-offs
Recovery
Option A
Invest in more platform automation for all services
Option B
Consolidate cohorts whose independence is unused
Recommendation:Fix platform gaps where services have real value; consolidate boundaries that deploy, fail, and change together.
Recovery target
Option A
One large monolith
Option B
A small number of modular, cell-deployed domain units
Recommendation:Prefer cohesive modular units with cell isolation, retaining services for genuine scale, trust, or ownership boundaries.
Follow-up interview questions
- 01How do you distinguish a bad boundary from a weak platform?
- 02Which services should remain separate?
- 03How do you tell executives the prior strategy was wrong?
- 04What prevents the consolidated unit becoming a new big ball of mud?
Common weak answers and mistakes
- 01Merging every service because service count is high.
- 02Treating consolidation as an admission of team failure.
- 03Recombining runtime while leaving duplicate data and events.
- 04Removing network boundaries without enforcing internal module and authorization rules.
Interviewer evaluation rubric
Argues monolith versus microservices ideologically and cannot classify which boundaries create value.
Uses coupling evidence, identifies cohorts, preserves modules, pilots consolidation, and measures outcomes.
Aligns team ownership, data authority, cell isolation, security, platform investment, and respectful change management.
Reverses a high-status strategy without organizational damage and establishes durable criteria for future boundary decisions.