Where this domain touches its neighbours

Data Engineering does not own the depth of anything below it. It owns what happens to a record between the system that wrote it and the person who believes it — and knowing exactly where that ends is what stops a curriculum from re-teaching its neighbours badly.

Every seam below is a place where a property is inherited rather than chosen. A pipeline does not decide its ordering guarantee, its delivery semantics or its consistency model; it receives them from the weakest hop and then has to live with them. Most of the incidents in this domain are a neighbour's property arriving somewhere nobody expected it.

The seams

What connects here, and where the depth actually lives. The second column is the one that keeps this domain honest.

Database EngineeringGo to Database Engineering →
The seam
The write-ahead log. Almost every mechanism a source database uses to stay correct decides what a pipeline downstream of it is able to promise.
Where the depth lives
Storage engines, indexes, transactions, isolation levels, MVCC and replication. If the question is how the source keeps its own data correct, it is theirs.
Backend EngineeringGo to Backend Engineering →
The seam
The service that produced the write, and the event it did or did not emit alongside it. A dual write is a backend decision with data-platform consequences.
Where the depth lives
Request handling, idempotency at the API boundary, outbox patterns, queues as application infrastructure, and the transactional guarantees of the write itself.
Systems ArchitectureGo to Systems Architecture →
The seam
Event-driven design, fan-out, and the difference between a queue used to decouple two services and a log used as a source of truth.
Where the depth lives
Service decomposition, distributed transactions, sagas, CQRS and the consistency models the whole system operates under.
Cloud & InfrastructureGo to Cloud & Infrastructure →
The seam
Object storage: immutable, listed rather than traversed, charged per request as well as per byte. Every atomic-publish pattern in this domain is an accommodation of that.
Where the depth lives
The storage primitives themselves, identity and access, networking, cost models and what a managed service actually manages.
Observability & PerformanceGo to Observability & Performance →
The seam
Pipeline health is not data health. They monitor whether the system is working; this domain monitors whether the data is right, and the two have almost no signals in common.
Where the depth lives
Metrics, traces, profiling, latency analysis and the question of why something is slow — a different question with a different toolkit.
SecurityGo to Security →
The seam
Classification, PII, minimisation, retention and deletion, applied to datasets and pipelines rather than to endpoints. Every copy inherited the obligation and none of the enforcement.
Where the depth lives
Threat modelling, authentication and authorisation mechanisms, encryption, and the adversarial reasoning this domain applies rather than invents.
Agentic & AI SystemsGo to Agentic & AI Systems →
The seam
Retrieval corpora, embeddings, evaluation sets and agent traces are data products with a grain, a schema, freshness, lineage and cost. Re-embedding is a data migration.
Where the depth lives
Model behaviour, prompting, evaluation methodology and agent design. This domain owns the pipelines that feed and measure them.

The connection lessons

One per neighbour, each written from the seam rather than from a summary of the other domain.

Module →
Data Engineering and Database Engineering

The seam is the write-ahead log. Almost every mechanism a source database uses to stay correct decides what a pipeline downstream of it is able to promise.

Q · Which parts of database internals does a data engineer genuinely have to understand, and which are somebody else's depth?Data Engineering and Distributed Systems

A pipeline does not choose its guarantees. It inherits them from the weakest hop, and most pipeline bugs are a distributed-systems property arriving where nobody expected it.

Q · Which distributed-systems guarantees does a data pipeline actually depend on, and what breaks when they do not hold?Data Engineering and Backend Engineering

The backend produces transactions, events and logs as a side effect of serving users. We are its downstream consumer, and it usually does not know that.

Q · What does a data platform need from the services that produce its data, and what is unreasonable to ask of them?Data Engineering and Cloud Infrastructure

A data platform is assembled almost entirely from four cloud primitives. Knowing which four, and what each actually charges you for, is most of platform engineering.

Q · Which cloud primitives is a data platform actually built from, and which decisions about them are irreversible?Data Engineering and DevOps

Transformation code deploys like software. The tables it already wrote do not, and that asymmetry is the whole lesson.

Q · What does it mean to deploy, version and roll back a change when the artefact is not a service but a table full of history?Data Engineering and Observability

Observability & Performance owns why it is slow. This domain owns whether it is correct, complete and fresh. Different questions, different signals, different toolkits.

Q · Why is monitoring a data platform a different discipline from monitoring a service, and which signals belong to which?Data Engineering and Security

A pipeline is a machine for making copies. Every copy inherits the original's obligations and none of the mechanisms that were enforcing them.

Q · What changes about access, classification, retention and deletion once data leaves the system that was protecting it?