DATA SYSTEMS, CLEARLY MAPPED   ·   Independent field guide
Stack Operators
Home / Architecture Notes
Patterns, trade-offs, decisions

Architecture notes for teams building in the open.

Short conceptual guides to help data teams describe the system they have, choose the next useful improvement, and avoid complexity without a clear job.

Core patterns

Start with a small number of clear contracts.

Patterns are useful when they reduce repeated decisions and make failure easier to detect. Adopt them deliberately and revisit them as the system changes.

PATTERN 01

Source-aligned landing

Preserve a traceable copy of source records and record when and how they arrived.

PATTERN 02

Layered transformation

Separate source cleanup, reusable business logic, and consumer-ready models.

PATTERN 03

Metadata with the code

Keep descriptions, tests, owners, and dependencies near the models they describe.

PATTERN 04

Small blast radius

Use modular boundaries and staged releases to limit the impact of a change.

An architecture review

Ask what becomes easier after the change.

  • Which user or operating problem does it address?
  • Does it reduce duplicated logic or just move it?
  • Can owners observe freshness, cost, and failures?
  • Can another team use the data safely?
  • What new operational burden does it add?
# Keep an architecture decision record
context: what is changing?
decision: what did we choose?
alternatives: what did we compare?
consequences: what gets easier or harder?
owner: who will review it later?
Continue learning

Go deeper by layer.