A small parks department is still discovering its domain model for a new reservation system and currently ships weekly with one modular deployable. When is keeping a well-modular monolith the more honest choice?
Select an answer to reveal the explanation.
Short Explanation
Monolith versus microservices is a trade-off, not a slogan. While the domain is still settling, a modular monolith can be simpler to transact, trace, and operate. Splitting too early buys distributed pain without independent deployability.
Full Explanation
Keeping a well-modular monolith is the more honest choice for the parks department while the domain is still settling and splitting into network-separated services would buy distributed failure modes without real shipping independence yet. Weekly delivery of one modular deployable can remain simpler to transact, trace, and operate until bounded contexts and team ownership are clear enough that independent deployability pays for its complexity.
Never starting as anything but dozens of network-separated services is slogan-driven design that ignores discovery cost and operational overhead for a small department. Waiting until the database schema is already split across twenty services reverses the lesson—you have already paid distributed-data cost, often without clean boundaries. Packing processes onto one Always Free instance because of Free Tier limits is a billing constraint, not a sound criterion for monolith-versus-microservices judgment.
Exam caveat: monolith versus microservices is a trade-off timed to domain clarity and team autonomy; “microservices always” and Free Tier packing rules are not the decision framework.
Operational check: review whether two candidate modules can already ship, scale, and fail on separate trains with clear contracts; if not, keep the modular monolith and strengthen module boundaries until that test passes.