Microservices Architecture and Service Decomposition Questions

Direct answer
A shared database accessed by many services is operationally simple (one place to back up, one place to query for a report, easy cross-table joins) but structurally couples every service that touches it: a schema change by one team can silently break another team's queries, and there's no way to enforce that only one service writes a given piece of data. Database-per-service removes that coupling, giving each service full control over its own schema and enforcing that it's the only writer of its data, at the cost of needing an explicit strategy for anything that used to be a simple SQL join across tables now owned by different services.

Structured elaboration
With a shared database: cross-service joins are trivial (a single SQL query spanning tables owned by different logical services), transactions across what should be service boundaries are easy (a single atomic, consistent, isolated, durable (ACID) transaction updating two tables), and reporting/analytics can query the whole dataset directly without needing to assemble it from multiple sources. The cost is that these are exactly the things that make it hard to deploy services independently: a schema migration has to consider every service that touches the affected tables, not just the service that conceptually owns them, and there's no enforced boundary preventing one service from reaching into data it doesn't really own.

With database-per-service: each service's schema can evolve on its own release schedule, because no other service can be broken by a change to tables it never had direct access to. The costs show up wherever data used to be joined or transacted across what are now separate services: a query that used to be one SQL join becomes either a replicated read model, an API composition call, or a purpose-built reporting/analytics pipeline that consolidates data from every service (commonly by consuming each service's event stream into a data warehouse); a transaction that used to be a single ACID commit across two tables becomes a saga or another cross-service coordination pattern, accepting eventual consistency where strict atomicity used to be free; and data duplication becomes a deliberate, managed trade-off (a service caching a read-only copy of data it needs from another service) rather than an accident.

Worked example
For reporting and analytics specifically, database-per-service usually means building a separate analytical store (a warehouse or lake) fed by each service's change-data-capture stream or event log, rather than pointing a business-intelligence (BI) tool directly at production service databases; this avoids both the tight coupling of shared production tables and the load a heavy analytical query would otherwise put on a service's transactional database. The operational implications differ sharply by pattern: with a shared database, one team's bad migration or one runaway analytical query can degrade every service at once (a single failure domain); with database-per-service, a failure or slow query in one service's database is isolated to that service, at the cost of needing per-service backup, monitoring, and on-call rather than one shared setup.

Direct answer
A pragmatic Domain-Driven Design (DDD) driven decomposition process for a large, high-traffic monolith runs in four stages: domain discovery with the people who actually understand the business, drawing candidate bounded contexts from that discovery, validating those candidates against real usage data before committing to extraction, and extracting the first service behind a boundary that also decouples it with domain events rather than direct calls.

Structured elaboration
Domain discovery typically uses a facilitated exercise like event storming, where domain experts and engineers map out the business events that happen in the system (OrderPlaced, PaymentAuthorized, InventoryReserved) without worrying about current code structure; clusters of related events and the language used to describe them are the raw material for candidate bounded contexts. From there, candidate contexts get validated against real signals before any code moves: does this candidate context have a genuinely different team owner, a genuinely different release cadence, or genuinely different scaling needs from its neighbors? A lightweight way to validate is a lower-cost spike, like standing up the candidate service's interface behind a feature flag while the implementation still lives in the monolith, or examining real consumer-usage data (which callers actually depend on this piece of functionality, and how tightly) before extraction.

Once a candidate is validated, extraction proceeds by first identifying the domain events the new context needs to publish or consume (OrderPlaced triggering a downstream Inventory reservation, for example) so that the new service is decoupled from its neighbors through events rather than direct synchronous calls into the old monolith's internals. Pitfalls to avoid at this stage: a shared-database anti-pattern, where the new service and the old monolith both read and write the same tables during a transition period (this defeats the purpose of the extraction and makes rollback harder, not easier); premature splitting, extracting a context before its boundary and ownership are validated, which tends to produce a service that has to be pulled back or merged with another later; and lack of ownership, extracting a service without a clear team committed to operating it, which leaves it as an orphaned piece of infrastructure nobody prioritizes maintaining.

Worked example
For a monolith that needs to split along bounded contexts under real traffic, a practical sequencing is: run event storming with the Payments and Fulfillment domain experts, notice that "Order" means two different things in each conversation, treat that as the boundary signal, validate by checking how many call sites in the current monolith actually cross that boundary versus stay within it (a high cross-boundary call count is a red flag that the proposed split doesn't match how the code is actually used today), and only then extract Fulfillment as its own service, publishing an OrderPlaced event that Fulfillment subscribes to instead of the monolith calling into Fulfillment's code directly.

Trade-offs and pitfalls
The single most common failure in this process is skipping the validation step and going straight from a whiteboard exercise to extraction, because the whiteboard boundary that looked clean in a discovery workshop often doesn't match how the current code and its call graph are actually structured; validating against real usage data before extracting is what prevents a costly "extract, discover it's wrong, and merge it back" cycle.

Direct answer
For a monolith covering catalog, cart, order processing, payment integration, user accounts, and search/recommendations, a reasonable first-pass decomposition draws boundaries around Catalog, Cart, Order, Payment, Account, and Search/Recommendations as separate services, each owning its own data, with Order acting as the coordinator for the checkout flow rather than Payment or Cart reaching into each other directly.

Structured elaboration
Per service:

• Catalog: owns product data (price, description, availability metadata); read-heavy, so it's a natural candidate for aggressive caching and can be scaled independently of the write-heavy parts of the system.
• Cart: owns the in-progress cart state per user; needs low-latency reads and writes but tolerates being eventually consistent with Catalog's pricing (a stale price shown briefly in the cart is a minor issue compared to blocking every cart operation on a live Catalog call).
• Order: owns the record of a placed order and coordinates the checkout flow; this is the service that calls Payment and reserves inventory (through Catalog or a dedicated Inventory boundary, depending on how far you want to split it), rather than the client calling Payment and Cart independently.
• Payment: owns payment-method data and transaction state; kept narrowly scoped because of its compliance and security surface, and communicates with Order via a well-defined API rather than sharing a database.
• Account: owns user identity and profile data, consumed by nearly every other service for authorization context.
• Search/Recommendations: owns a derived, denormalized view built from Catalog and behavioral data; naturally asynchronous, since search indexes and recommendation models don't need to reflect a catalog change within milliseconds.

The boundaries are justified by data ownership (each service is the only writer of its own tables) and by differing scaling and team-ownership needs (Catalog and Search are read-heavy and can scale independently of the write-heavy Order/Payment path; a payments-compliance team plausibly owns Payment separately from the team that owns the general shopping experience).

Worked example
The "place order" flow, which needs both payment and inventory reservation to succeed, works like this: Order receives the checkout request, calls Catalog/Inventory to reserve stock (a short-lived hold, not a permanent decrement), calls Payment to authorize the charge, and only commits the order and the inventory decrement once both steps succeed; if the payment authorization fails, Order releases the inventory hold. This keeps Order as the single owner of the multi-step process instead of scattering that coordination logic across Cart, Catalog, and Payment, each of which would otherwise need to know about the others' state.

Trade-offs and pitfalls
The boundary most people get wrong first is putting Cart and Order in the same service because they seem closely related; keeping them separate matters because Cart's access pattern (many small, low-stakes reads and writes per browsing session) is very different from Order's (fewer, higher-stakes, must-be-durable writes), and merging them tends to drag Order's stricter consistency and auditability requirements onto Cart's much higher-volume, lower-stakes traffic. As the product scales, the decomposition decision most likely to be revisited is whether Inventory should split out of Catalog into its own service, since inventory correctness (avoiding overselling) has fundamentally different consistency requirements than serving catalog browsing pages, and coupling the two forces Catalog's read-heavy scaling story to carry Inventory's stricter write guarantees.

Direct answer
The three main approaches to data ownership across microservices are: a single service acting as the source of truth that everyone reads from directly (simplest to reason about, but couples every reader to that service's availability and latency), replicated read models kept in sync via events (readers query their own local, eventually-consistent copy, trading a small consistency lag for independence and speed), and API composition at query time (a caller assembles the answer by calling several owning services and combining the results, keeping strong consistency but adding latency and coupling every read to every owner's availability).

Structured elaboration
Single-source-of-truth reads are the right default when correctness matters more than the reading service's independent availability and latency, and when the read volume is low enough that hitting the owning service directly doesn't become a bottleneck. Replicated read models are the right choice when a consumer needs low-latency, high-volume reads and can tolerate a short staleness window (seconds, not hours); the owning service publishes a canonical event stream whenever its data changes, and consumers build their own read-optimized copy from that stream. API composition sits in between: it avoids duplicating data (nothing is replicated, so there's no staleness to manage) but every composed read now depends on every service it calls being up and fast, which can turn a simple query into a slow, fragile fan-out if not designed carefully (with timeouts, partial-result handling, and caching where it matters).

Worked example
For a product needing low-latency pricing reads with eventual consistency acceptable for inventory: pricing, which changes relatively rarely and needs to be read extremely fast on every product page, is a strong candidate for a replicated read model, cached aggressively in the reading service and refreshed via a Pricing-changed event stream. Inventory, where eventual consistency is explicitly acceptable, can also use a replicated model, refreshed on its own change stream, with the understanding that a very recent update might lag by a second or two before every reader sees it. Where a query needs fields owned by two different services and there's no dedicated read model built for that exact combination, the fallback is API composition: call Pricing and Inventory in parallel, with a timeout and a documented fallback (like showing a cached last-known price) if one of them is slow, rather than letting the whole page hang on the slowest owner.

Trade-offs and pitfalls
The most common mistake with replicated read models is treating the replicated copy as a second source of truth and allowing writes against it, which reintroduces exactly the data-ownership ambiguity the pattern was meant to avoid; a replicated read model should always be read-only, with all writes going through the owning service's canonical event stream. The most common mistake with API composition is skipping timeout and partial-failure handling, so a single slow downstream service degrades every caller's latency instead of being isolated to just the field it owns; a well-designed composition layer degrades gracefully (showing what it has, with a clear fallback for what it couldn't fetch in time) rather than failing the whole request.

Direct answer
Decomposing a monolith into many small services shifts operational load from "deploy and operate one thing" to "deploy and operate N things," which multiplies the number of deployment pipelines, the number of places an incident can originate, and the number of services someone needs to be paged for, so the operations model needs to change deliberately (routing, on-call structure, alerting design) rather than simply scaling the old monolith-era practices across more services.

Structured elaboration
Deployment pipelines: a monolith has one pipeline to maintain and improve; N services means N pipelines unless there's a shared, templated deployment approach, so investing in a standard, reusable pipeline template early (rather than letting each service reinvent its own) is what keeps this from becoming N times the maintenance burden. Incident management: with a monolith, on-call needs deep familiarity with one large system; with many services, on-call needs either broad familiarity with many smaller systems (harder to maintain deep expertise in each) or a routing mechanism that pages the specific team owning whichever service is actually failing, which requires accurate service ownership metadata and alerting configured per service rather than one undifferentiated alert stream. On-call rotation: the natural model shifts from one shared rotation covering the whole monolith to per-team rotations, each covering the services that team owns, which requires clear, unambiguous ownership (no orphaned or ambiguously-owned services that nobody is actually on call for).

Worked example
As service count grows, avoiding alert fatigue specifically requires: routing alerts to the team that actually owns the failing service (rather than a single shared on-call rotation getting paged for every service in the fleet, most of which they don't know well), distinguishing service-level-objective (SLO) impacting alerts (a customer-facing symptom worth waking someone up for) from purely internal or low-severity signals (which can wait for business hours or go to a dashboard instead of a page), and periodically reviewing alert volume per service to catch and fix a chronically noisy alert rather than letting on-call engineers learn to ignore it, since an alert that's routinely ignored provides no real protection when it matters.

Trade-offs and pitfalls
The common failure as service count grows is not investing in the operational tooling (service ownership catalog, alert routing, shared pipeline templates) at the same time as the service count grows, so the org ends up with 50 services and still a single undifferentiated on-call rotation and alert stream, which reliably produces alert fatigue and slow incident response, since the person paged often isn't the person who actually understands the failing service. The fix is treating the operations model itself as something that needs deliberate investment alongside the architectural decomposition, not an afterthought that scales itself.