A property-tax assessment update must write both the assessed value and the related lien flag in one commit, and both fields always change on the same release cadence. What should the team do about service boundaries?
Select an answer to reveal the explanation.
Short Explanation
Some ledgers must flip two columns together—like stamping both pages of a dual-entry book. Forcing those pages into separate buildings just so you can call them “microservices” usually creates more pain than freedom.
Full Explanation
Cohesion and a hard single-commit need are valid reasons to keep a boundary closed. Assessed value and the related lien flag must succeed together on the same release cadence, so keeping that transactional core in one deployable avoids inventing a distributed transaction just to claim “microservices.” Prefer one unit of deployment until data ownership and change cadence truly diverge—maturity over premature split for a property-tax write path.
Splitting immediately and inventing a distributed transaction across a chatty pair adds failure modes (partial commit, locks, compensating chaos) without a clear independent-scale or independent-team payoff. Putting each write in a separate eventual-consistency saga when they must succeed together weakens a correctness requirement the domain already stated. Exposing both writes only through separate public APIs with no shared transactional boundary invites inconsistent states citizens would see as broken tax records.
Exam caveat: “keep together for now” is not forever—revisit the boundary when teams, scale, or schemas diverge; the exam rewards recognizing when not to split. Operational check: assert in integration tests that assessed value and lien flag either both persist or both roll back on a forced mid-write failure, and track whether their change tickets still always ship together.