Northline Retail: Justifying a Service Split Under Cost and Consistency Constraints
Northline Retail's order platform is a 14-year-old Java monolith of 3.1 million lines running on 38 application servers. Forty-two teams commit to the same repository; the release train ships every six weeks, while the business now asks for three production releases per week. Peak traffic is 22,000 requests per second, and the checkout p95 latency is 1.8 seconds against an 800 ms service-level objective. The platform shares one Oracle database across all modules. Six SREs support the system. The chief architect proposes splitting it into nine domain microservices, each with its own datastore, and claims the change will be cost-neutral. The CFO requires no increase in run-rate spend. Audit requires a seven-year trace of price changes. Two teams already own clear bounded contexts; the rest are organized by technical layer.
1. Assess whether the proposed nine-service split is architecturally justified. Identify the principles and quality-attribute trade-offs you would document, and state your recommendation with the first three steps.
Read the worked answer
Separate the driver from the proposed solution
The driver is release cadence: three production releases per week versus a six-week train. Microservices are one tactic, not the requirement. The evidence points to a coordination problem: 42 teams share one repository and one Oracle schema. Only two bounded contexts are clearly owned; the rest are layered, so a nine-way split would cut across team and data boundaries rather than follow them.
Principles to document
Record principles with rationale, implications, and exceptions: independent deployability; data ownership by one service; API-first contracts; observability by default; traceability of price changes; cost transparency per service. A principle without an exception process becomes a slogan.
Trade-offs to make explicit
- Consistency versus autonomy: splitting the database turns strong transactions into sagas and projections.
- Latency versus isolation: network hops may worsen the 1.8 s p95; profiling is needed before decomposition.
- Team autonomy versus platform standardization: nine datastores and nine deployment pipelines increase the load on six SREs.
- Cost neutrality versus resilience: duplicated infrastructure and observability usually raise run-rate spend.
- Auditability versus distribution: a seven-year price trace requires correlation IDs and an immutable event log.
Recommendation
Do not approve a big-bang nine-service split. Modularize around the two real bounded contexts, extract two or three high-value contexts first using a strangler approach, and keep the shared database only where a migration path is defined. Establish fitness functions for lead time, p95 latency, change failure rate, and cost per transaction.
First three steps
- Run dependency and data-ownership analysis to confirm seams.
- Define target quality-attribute scenarios and measure the current checkout path.
- Pilot one extraction with a dedicated team, then review cost and reliability data before expanding.
2. The principles "independent deployability" and "a single source of truth for inventory" conflict. Show how you would resolve and record the conflict so teams and auditors can follow the outcome.
Read the worked answer
Reframe the conflict
A single source of truth does not have to mean a single physical database. It can mean one authoritative writer and a defined consistency contract for readers. Independent deployability does not require every service to own a private copy of all data; it requires that a service can change and deploy without coordinating a release with another team.
Resolution
Make the inventory service the only writer of stock levels. Other services read through an API or consume events and maintain projections. Define a staleness service-level objective, for example 99% of projections reflect stock within two seconds. If pricing needs a local cache to deploy independently, document the cache, its eviction rule, and the acceptable staleness. Keep an immutable event log to satisfy audit traceability.
Record the decision
Use an architecture decision record containing: title, status, context, decision, alternatives considered, consequences, related quality-attribute scenario, owner, and review date. Add a principle-exception entry if the decision departs from the default. Link the decision to the relevant views and to the audit control it supports.
Make it enforceable and visible
Add fitness functions that check event publication, projection lag, and audit completeness. Publish the decision in the architecture repository and mention it in onboarding. Auditors should be able to follow the chain from the price-change requirement to the event log, the decision record, and the monitoring evidence.
Governance
Do not let either principle win silently. The chief architect or architecture board should approve the exception with a named owner and an expiry or review date. If projection lag breaches the objective, the exception is revisited rather than treated as permanent.