> ## Content Index
> Fetch the complete content index at: https://engineeringparanoia.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Hands off my table: The single writer principle
- URL: https://engineeringparanoia.com/data-ownership-single-writer-principle/
- Published: 2026-09-10T18:52:58.000Z
- Updated: 2026-09-11T20:55:04.000Z
- Description: A table doesn't need to be democratic. When multiple processes write on the same table, ownership becomes blurry, failure becomes harder to reason about and your manager start asking "who changed this?"
- Author: Marco Trombino
- Tags: Data Engineering, Big Data

A crystal-clear **data flow** is what separates a well-structured system from a production nightmare: it makes the system easier to understand, define clear boundaries and responsibilities and ensure robustness when things go wrong.  
That is why data flow having direct impact on:

- *Software quality*: by keeping components cohesive and loosely coupled
- *Activities decomposition*: by allowing work to be split into independent and parallelizable tasks
- *System resilience*: by making failures easier to understand, recover and replay

## Data Ownership

An important principle which should be within every engineer's swiss army knife is what *Zhamak Dehghani* defines as **Data Ownership** within her book [Software Architecture: The Hard Parts](https://www.oreilly.com/library/view/software-architecture-the/9781492086888/?ref=engineeringparanoia.com).  
  
The principle states that data ownership must be defined for every table involved in the data flow:

> The general rule of thumb for data ownership is that the service that performs **write operations** to a **table** is the **owner** of that table.

Within the book, Zhamak covers many data ownership scenarios (from the straightforward ones to most complex ones) and offers useful criteria to assign proper ownerships.

## The Single Writer Principle

In its straightforward scenario (single table ownership), *Zhamak*'s Data Ownership resembles *Martin Thompson*'s [Single Writer Principle](https://mechanical-sympathy.blogspot.com/2011/09/single-writer-principle.html?ref=engineeringparanoia.com) which highlights the benefits of designing systems which remove or minimize data contention.

## Apply The Principles

Given the fact that managing data contention is often a big pain point of distributed systems, a rule of thumb is trying to model any data flow using **single table ownership**.  
Whenever data from different sources needs to be written into the same target table two approach can be used: Data staging and Data queueing.

### Data staging

Let N intermediate writers write into their own staging area (e.g. a plain files path or a table). Then, let one and only one final writer read the N staged dataset and write into target table.

```mermaid
flowchart LR
    A["Writer 1"]:::adkJob
    C["Writer 2"]:::adkJob
    E["Writer N"]:::adkJob
    G["Writer N+1"]:::adkJob
    B@{ icon: "adk:table", label: "staging_1" }
    D@{ icon: "adk:table", label: "staging_2" }
    F@{ icon: "adk:table", label: "staging_N" }
    H@{ icon: "adk:table", label: "final" }
    A e1@--> |write| B
    C e2@--> |write| D
    E e3@--> |write| F
    B e4@--> |read| G
    D e5@--> |read| G
    F e6@--> |read| G
    G e7@--> |write| H
    
    class e1,e2,e3,e4,e5,e6,e7 adkHot
```

### Data queueing

Let N intermediate writers write into a queuing system. Then let one and only one final writer read from the queue and write to target table.

```mermaid
flowchart LR
    A["Writer 1"]:::adkJob
    C["Writer 2"]:::adkJob
    D["Writer N"]:::adkJob
    E["Writer N+1"]:::adkJob
    B@{ icon: "adk:queue", label: "queue" }
    F@{ icon: "adk:table", label: "final" }
    A e1@--> |write| B
    C e2@--> |write| B
    D e3@--> |write| B
    B e4@--> |read| E
    E e5@--> |write| F
    class e1,e2,e3,e4,e5 adkHot

```

### **Alternatives**

If concurrent writers are absolutely necessary, eliminate **concurrency issues** by performing **disjoined writes** (e.g. [disjoined partitioned writes](https://docs.databricks.com/aws/en/optimizations/isolation/row-level-concurrency?ref=engineeringparanoia.com#avoid-conflicts-using-partitioning)) into ACID table formats such Iceberg, Delta Lake, Hudi.