Chapter 9 Flashcards — Data Ownership and Distributed Transactions
flashcards saht data-ownership distributed-transactions eventual-consistency
What is data ownership in the context of distributed microservices architecture?
?
Data ownership means the single service responsible for writing to (and therefore controlling) a particular table or data entity. Other services may read that data through APIs, but only the owner writes to it directly. Read access is a separate concern from ownership.
What are the three data ownership scenarios described in SAHT Chapter 9, in order of difficulty?
?
- Single ownership — exactly one service writes to a table (easiest).
- Common ownership — multiple services read from the same reference/infrastructure table; no service truly “owns” it in a business sense (manageable).
- Joint ownership — two or more services both need to write to the same table (hardest; requires explicit resolution).
What is single ownership and why does it require no special resolution?
?
Single ownership means exactly one service writes to a given table. Other services may read via API, but never write directly. Because there is no ownership conflict, you simply assign the table to that service. It is the natural, easy case — most tables in a well-decomposed system should fall into this category.
What is common ownership and what are the typical resolution options?
?
Common ownership applies when multiple services need to read from shared reference/lookup data (e.g., zip codes, country codes, product categories) that belongs to no single business domain. Resolution options:
- Create a dedicated reference data service that owns and exposes the data via API.
- Replicate the reference data into each service’s own schema (periodic sync).
- Allow a shared read-only schema for purely static data (pragmatic exception to per-service DB rule).
What is joint ownership and why is it the hardest data ownership scenario?
?
Joint ownership occurs when two or more services both need to write to the same table. It is hard because: you cannot assign ownership to one service without blocking the other’s write access; you cannot share the table without creating tight database coupling (defeating decomposition); and every resolution technique involves a trade-off between coupling, data integrity, and complexity.
What are the four techniques for resolving joint ownership?
?
- Table Split — split the shared table into separate tables, each owned by one service (partition by columns).
- Data Domain — create a bounded shared schema both services write to (controlled exception to per-service DB).
- Delegate — designate one service as the sole owner; the other service calls the owner’s API for all writes.
- Service Consolidation — merge the two services into one; the ownership conflict disappears.
Describe the Table Split technique for resolving joint ownership. When does it work best?
?
The table is analyzed by which columns each service writes to. The table is split into two tables sharing a common primary key. Each service owns and writes to its own table only.
Works best when: column boundaries map cleanly to service boundaries with minimal or no overlap. If both services write to the same column (e.g., a shared status field), a split alone is insufficient. Trade-off: referential integrity must be enforced at the application layer, not the database.
Describe the Data Domain technique for resolving joint ownership. What is its main risk?
?
A bounded shared schema (data domain) is explicitly created and shared between the two services that both need write access. It is a deliberate, documented exception to the “one database per service” rule.
Main risk: scope creep — other services may start accessing the shared domain, gradually recreating a monolithic shared database. Requires strong governance to keep the domain boundary tight.
Best for: situations where data integrity across writes is non-negotiable and the sharing scope is strictly limited.
Describe the Delegate technique for resolving joint ownership. What is its main failure mode?
?
One service is designated the true owner of the table. Any other service that previously wrote to the table must now send write requests to the owning service’s API; it never touches the database directly. The owner enforces all validation and business rules.
Main failure mode: the non-owning service is tightly runtime-coupled to the owner. If the owner is unavailable, the non-owner cannot perform writes. Circuit breakers and retry logic are essential. Also introduces extra network latency per write.
Describe the Service Consolidation technique for resolving joint ownership. When is it the right choice?
?
The two services are merged into one larger service with a single database. The joint ownership problem disappears because there is only one service and one owner.
Right choice when: the services are more semantically cohesive than originally thought; the operational coupling between them is already high; or other techniques are too complex given the team’s constraints. Service consolidation is a valid granularity integrator — it is not a design failure.
How do you choose among the four joint ownership resolution techniques?
?
- Can you cleanly partition columns by service? → Table Split
- Is data integrity across writes non-negotiable? → Data Domain (controlled shared schema)
- Is one service the clear semantic owner? → Delegate
- Are the two services more cohesive than originally decomposed? → Service Consolidation
If none of the above apply cleanly, revisit whether the original domain decomposition is correct.
Why does ACID fail across service boundaries in a microservices architecture?
?
Each service has its own database. An operation spanning two services must write to two separate databases. There is no native mechanism to make these writes atomic. If the second write fails, the first write has already committed and cannot be rolled back — the system is left in an inconsistent state. You would need an external distributed transaction protocol to coordinate, which introduces its own problems.
What is Two-Phase Commit (2PC) and what are its two phases?
?
2PC is a distributed transaction protocol where a coordinator ensures all participants either commit or roll back together.
- Phase 1 (Prepare): Coordinator sends PREPARE to all participants. Each writes pending changes to a durable log and replies READY or ABORT.
- Phase 2 (Commit/Rollback): If all replied READY, coordinator sends COMMIT to all. If any replied ABORT, coordinator sends ROLLBACK to all.
What are the four main problems with using 2PC in microservices?
?
- Blocking protocol: If the coordinator crashes between phases, participants hold locks indefinitely waiting for resolution.
- Synchronous coupling: All participants must be available simultaneously; probability decreases with number of participants.
- Lock contention: Participants hold database locks across both phases, causing severe contention under high concurrency.
- HTTP incompatibility: 2PC (XA protocol) was designed for database-level coordination, not HTTP-communicating services — XA-aware resource managers are extremely rare in microservices stacks.
What is the Background Synchronization pattern for eventual consistency?
?
Each service performs its local operation independently. A separate background process (batch job, reconciliation service, or scheduler) periodically queries multiple services’ data, detects inconsistencies, and issues corrective writes. No synchronous coordination between services at request time. Consistency lag equals the reconciliation interval (minutes to hours).
What are the trade-offs of the Background Synchronization pattern?
?
Strengths: Very low architectural complexity; services remain fully decoupled; easy to implement and reason about.
Weaknesses: High consistency lag (minutes to hours); the background job is a single point of failure; if the sync job fails, inconsistency persists until recovery; stale reads during the window between sync runs.
Best for: Reporting databases, analytics aggregations, financial reconciliations, non-critical summaries where staleness is tolerable.
What is the Orchestrated Request-Based pattern for eventual consistency?
?
A central orchestrator service calls participating services in sequence over synchronous HTTP/gRPC. If any step fails, the orchestrator issues compensating transactions to the previously successful steps, logically undoing them. The orchestrator manages the workflow state and failure recovery explicitly.
What is a compensating transaction in the Orchestrated Request-Based pattern?
?
A compensating transaction is a forward-moving operation that logically undoes a previously committed step. It is not a database rollback — the original write is already committed. Examples: if “create ticket” succeeded but “assign expert” failed, the compensating transaction is “cancel/delete ticket.” Compensating transactions must be:
- Idempotent — safe to call multiple times.
- Explicitly designed — the orchestrator must know what to call for each failure scenario.
- Themselves reliable — a failed compensation is a serious problem requiring manual intervention.
What are the trade-offs of the Orchestrated Request-Based pattern?
?
Strengths: Consistency window is the workflow duration (seconds); explicit failure recovery via compensations; easier to reason about and debug than async patterns; audit trail of orchestrator state.
Weaknesses: Orchestrator is a single point of failure; orchestrator can become a bottleneck; compensation chains can be complex; synchronous calls add latency; orchestrator is coupled to all participant services.
Best for: Multi-step business workflows with a defined sequence and known failure recovery paths.
What is the Event-Based pattern for eventual consistency?
?
Services publish domain events to a durable message broker when they complete local operations. Other services subscribe and react to those events asynchronously. No synchronous coordination. Each service processes events at its own pace and maintains its own consistency. The broker buffers events, providing fault isolation between publisher and consumers.
What are the trade-offs of the Event-Based pattern?
?
Strengths: Very low service coupling (services share only event contracts); high fault tolerance (broker buffers events; consumer failures don’t affect publishers); high scalability (services and broker scale independently); high publisher responsiveness (fire and forget).
Weaknesses: High architectural complexity (event schema design, broker management, idempotency, ordering, distributed tracing); eventual consistency with variable lag; no rollback — compensations are themselves events; debugging is significantly harder.
Best for: High-throughput operations, fan-out notifications (one event → many consumers), domains where decoupling is paramount.
Why must event consumers in the Event-Based pattern be idempotent?
?
Message brokers typically guarantee at-least-once delivery — they may redeliver a message if the consumer processes it but crashes before acknowledging. If a consumer is not idempotent, duplicate event processing can cause double-counting, duplicate writes, or other data corruption. Idempotency means the consumer produces the same result whether it processes the event once or multiple times (e.g., using deduplication keys or checking current state before applying the event).
Compare the three eventual consistency patterns across consistency lag, coupling, and fault tolerance.
?
| Pattern | Consistency Lag | Service Coupling | Fault Tolerance |
|---|---|---|---|
| Background Sync | High (minutes–hours) | Very low | Low (sync job SPOF) |
| Orchestrated Request-Based | Low (seconds) | Medium | Medium (orchestrator SPOF; compensations) |
| Event-Based | Medium (ms–seconds) | Very low | High (broker buffers; independent recovery) |
No universal winner — choose based on consistency requirements, throughput, team capability, and tolerance for complexity.
What is the key difference between a compensating transaction (orchestrated pattern) and a compensating event (event-based pattern)?
?
Both logically undo a previous operation, but they differ in mechanism:
- Compensating transaction (orchestrated): The orchestrator synchronously calls a service’s API to reverse the prior step (e.g., calls DELETE on the Ticket Service). Procedural, immediate, synchronous.
- Compensating event (event-based): The originating service publishes a new event signaling the reversal (e.g.,
TicketCancelled). Downstream services that consumed the original event must subscribe to the compensating event and react. Asynchronous, eventually consistent, but maintains decoupling.
In the Sysops Squad saga, how did the team resolve the joint ownership conflict between the Ticket Service and Assignment Service?
?
They applied the Table Split technique: analyzed which columns each service wrote to, found a clean column boundary, and split the table. The ticket table (owned by Ticket Service) retains creation/lifecycle columns. A new ticket_assignment table (owned by Assignment Service) holds assignment-specific columns, linked by ticket_id. The resulting distributed transaction between the two services was handled with the Orchestrated Request-Based pattern — a practical choice given their team’s current lack of mature broker infrastructure.
In the Sysops Squad saga, how was the zip code lookup data ownership resolved?
?
Zip code data is needed by multiple services (Ticket, Customer, Assignment) but belongs to no single business domain — it is reference/infrastructure data. This is common ownership. Resolution: a small dedicated LocationReferenceService was created to own and expose the zip code data via API. All three services query it rather than each maintaining their own copy.
What does the book mean by saying that service consolidation is a valid granularity integrator, not a design failure?
?
In SAHT’s framework (see Chapter 7), granularity integrators are forces that push toward merging services — functional cohesion, database transactions, workflow, and shared code. When two services share such tight data coupling that all resolution techniques are more complex than simply merging, consolidation is the correct architectural response. It reflects an incorrect prior decomposition decision, not architectural weakness. The book treats it as a legitimate first-class technique alongside table split, data domain, and delegate.
What does it mean that eventual consistency patterns form a spectrum, and how should architects position along that spectrum?
?
The three patterns differ in the consistency lag they produce, the coupling they impose, and the complexity they require:
- Background Sync → highest lag, lowest complexity, lowest coupling.
- Orchestrated → lower lag, medium complexity, medium coupling.
- Event-based → lowest lag (async), highest complexity, lowest coupling.
Architects position along this spectrum based on: how long the business can tolerate inconsistency, whether the team can manage async debugging complexity, whether broker infrastructure exists, and whether the workflow has a definable failure recovery path. A single system may use all three patterns in different subsystems.
What two chapters in SAHT build directly on the eventual consistency patterns introduced in Chapter 9?
?
- Chapter 11 — Managing Distributed Workflows: Develops choreography (event-based) and orchestration workflow patterns in depth; covers the trade-offs between the two coordination styles at workflow granularity.
- Chapter 12 — Transactional Sagas: Provides a full catalog of saga pattern variants (Epic Saga, Phone Tag Saga, Fairy Tale Saga, etc.) built on top of the orchestrated request-based and event-based foundations introduced in Chapter 9.
Total Cards: 28
Priority: HIGH
Last Updated: 2026-05-30