A new product, one team of eight, uncertain requirements, ambitious growth plans. Monolith or microservices?

What the interviewer is testing

Whether you separate logical modularity from physical distribution, and whether you can argue against the "we will need to split later anyway" reasoning.

Why not microservices now

Boundaries are hard to get right and the requirements are uncertain. A boundary drawn now, before the domain is understood, will be wrong — and moving a boundary between services means data migration, contract changes and coordinated deployment. Moving one inside a monolith is a refactor.

One team of eight does not need independent deployment. The benefit microservices buy is team autonomy at a scale where coordination dominates. With one team, coordination is a conversation.

The costs arrive immediately: network calls with partial failure, distributed debugging, eventual consistency, deployment orchestration, and per-service operational overhead — all paid by eight people who should be finding product-market fit.

Why not an unstructured monolith

Because the growth plans may be real. A monolith with no internal boundaries becomes a system where nothing can be extracted, and the eventual split is a rewrite.

The recommendation

A modular monolith with automatically enforced boundaries. One deployable, one database, and modules that own their data and expose explicit interfaces — with an architecture test failing the build on cross-module violations, because a boundary maintained by convention erodes within months.

That gives clean domain separation, cheap boundary changes while understanding improves, local debugging, and one deployment.

When to extract

When a specific module has a genuine need: independent scaling, a different technology requirement, a separate team owning it, or a distinct compliance boundary. Extract that one. A well-enforced module is straightforward to extract — which is a far better position than discovering after distribution that the boundary was wrong.

What a strong answer adds

The corollary: the decision to split should be evidence-driven, and the evidence is team count, coordination cost and scaling pressure — not a growth projection. Splitting on a forecast is how organisations end up operating twelve services for a product with four hundred users.

Common weak answers

Microservices to avoid a later migration, which pays the full cost immediately for a benefit that may never be needed. A monolith with no boundary enforcement.