One developer maintains a small tool that enables a single guest SSID and appends an audit line. There is one release train and no independent scale need. Which architectural pattern is justified?
Select an answer to reveal the explanation.
Short Explanation
A one-person lemonade stand does not need four separate kitchens. A small SSID-enable tool with one change set is a justified monolith. Splitting into services before independent scale or release needs is ceremony.
Full Explanation
A monolith—one deployable that performs the guest-SSID enable and the audit log write—is justified when one developer maintains a small tool with one release train and no independent scale need. A one-person lemonade stand does not need four separate kitchens. Keeping enable and audit in one unit reduces operational ceremony, shared-schema drift, and release coordination for a change set that always ships together.
Four microservices with separate databases before any independent release pressure exists add distributed failure modes and deployment overhead without payoff. An enterprise service bus mandated solely by the word municipal confuses civic branding with integration necessity. Event-driven fan-out to twelve unknown consumers for a single synchronous UI click invents an audience and asynchrony the tool does not require.
Exam caveat: start monolithic when scale and release independence are absent, but revisit if enable and audit later need different SLAs, teams, or scale—do not treat monolith as permanent dogma. Operational check: measure whether enable and audit ever fail or deploy on different cadences in production; if they always move together under one owner, keep the single deployable and document that decision for the next architecture review.