One workstream on the modernisation project proposes drawing a service boundary for every database table in the schema. What is the risk?
Select an answer to reveal the explanation.
Short Explanation
Database tables are storage details. When you draw service boundaries around every table, you split operations that belong together and force distributed coordination across services that should have stayed one.
Full Explanation
Drawing service boundaries for every database table is risky because business operations frequently update several tables in one unit of work. Table-based splitting breaks those operations apart and requires distributed transactions to hold them together again. Logic and transactions that genuinely belong together get separated because they touch different tables, forcing distributed coordination across services that should have been one. The claim that table-based splits are rejected by modernization tooling and cannot be built is incorrect because the tooling will happily build whatever boundaries are specified; the problem is architectural, not build constraint. The claim that one table per service produces too few services to be useful is incorrect because the table-per-service rule typically produces too many fine-grained services, not too few. The claim that table-based boundaries make the resulting services impossible to test independently is incorrect because testability is secondary next to the transactional coupling this approach creates. For the exam, treat data ownership as one input to boundaries, not the sole rule.