Reference architectures

Patterns, with the
trade-offs written down.

Architectures we have built and would build again. Each one describes the shape, the guarantees you have to design for, where it breaks, and when to pick something else instead.

Integration platform

A message bus carries thin reference events — an ID plus the attributes you filter on. Subscribers read the full record back from the system of record and update their own store. No payloads on the bus.

Event-driven Azure Event Grid CloudEvents
Read the architecture →

Medallion lakehouse

Batch analytics in three layers. Bronze keeps what arrived, Silver turns it into conformed business entities, Gold answers specific questions. Everything after Bronze is derived — so every mistake is reversible.

Batch Databricks Delta Lake
Read the architecture →

Streaming analytics

The same three layers, with the clock running. Structured Streaming moves events continuously from Bronze to Gold — and the architecture is really about what gets harder once you can no longer wait for the data to be complete.

Streaming Databricks Event time
Read the architecture →

More on the way

We publish these as we build them. If there is a pattern you would like us to write up — or pull apart with you — get in touch.

Suggest one →

Which one applies

These three are not alternatives to each other — most organisations that need one eventually run all three. They sit at different points, and the question that separates them is not "how much data" but how fresh does it have to be, and who or what acts on it.

If this is true Start here Because
Several systems must react when a record changes in another system Integration platform The problem is coupling between operational systems, not analysis. Point-to-point integrations stop scaling at about the fourth system.
People need numbers they trust, and hours-old data is fine Medallion lakehouse The problem is shared definitions and reproducibility. Layering buys you the ability to fix a logic bug with a recompute rather than a data loss.
Something automated acts on the result within minutes or seconds Streaming analytics The value of the insight decays faster than a batch window. Worth the on-call burden only when a real decision depends on it.
You have one source, one dashboard and one person None of them, yet A scheduled query into a table is the correct architecture. Adopt a pattern when you have the problem it solves, not before.

How they fit together

In a mature platform the three compose rather than compete. The integration platform is how changes are announced across the organisation; the data platform is one more subscriber to it. The medallion layers describe what the lakehouse tables mean; streaming describes how often they are updated. A single Bronze table can be written by a stream and read by both a continuous Silver transform and a nightly batch correction job — that combination is normal, and it is what lets you have low latency without giving up the ability to reprocess.

The order we would adopt them

Batch medallion first, because it forces the definitional work — grain, keys, metrics — that the other two assume has already been done. Integration platform next, when the number of systems makes point-to-point untenable. Streaming last, and only for the specific pipelines that have a decision attached to them.

Skills that build these

Each of these architectures has a skill that implements it — the layer contracts, the idempotency rules and the operational scaffolding, packaged so an AI assistant applies them without being reminded. Browse the skills →