Lambda, Kappa, Medallion, Data Mesh, Data Lakehouse, and Semantic Architecture show up in almost every data architecture overview, usually as boxes with a one-line description each. That’s fine as a glossary, but it doesn’t tell you much about what happens once you build one. Here we go a layer deeper: for each pattern, we cover where it earns its keep, what it costs in practice, a concrete scenario where we’ve seen it work, and the implementation decisions that determine whether it holds up.

---

AI consumption is now the dominant pressure reshaping data architecture

The dominant pressure on data architecture is no longer simply analytics and integration. In 2026 it’s AI applications, AI agents, retrieval-augmented generation, semantic search, and autonomous decision-making, all of which consume data very differently to a BI dashboard or a nightly batch job.

Traditional architecture patterns were optimised for analytics and integration. Modern architectures must additionally support AI consumption.

That’s precisely where the canonical models, semantic contracts, and data products covered later in this paper earn their keep. An AI agent retrieving a customer record needs the same semantic clarity a human analyst does, arguably more, since there’s no analyst in the loop to catch a misunderstanding. Getting the contract right isn’t just an integration concern anymore: it’s what determines whether an AI system reasons about your data correctly at all.

An architectural style, not a pattern, determines how components interact

An architectural style is the underlying way components are allowed to interact. None of the six patterns is a style in itself: each one typically combines one or more of these building blocks.

The styles that come up most often are:

• Event-driven
• Pipeline-oriented
• Service-oriented
• Data-product-oriented
• Layered
• Distributed/decentralised
• Shared platform

A pattern can be implemented using one or more of these styles at once, which is part of why the six patterns don’t sit neatly at the same level.

Take Medallion as a worked example:

Medallion’s underlying architectural style is layered and pipeline oriented. That style shapes the Medallion pattern’s bronze, silver, and gold staging, which is governed by schemas and data contracts and typically implemented on Delta tables in Fabric or Databricks.

Each pattern maps to a different architectural style

Each of the six patterns, Lambda, Kappa, Medallion, Data Mesh, Data Lakehouse, and Semantic Architecture, relies on an underlying architectural style to establish how components are allowed to interact.

For example:

Architectural style	Typical interaction	Role of contracts
Lambda	Batch and streaming pipelines converging in a shared serving layer	Agreement on a common output schema so batch corrections and streaming results reconcile
Kappa	A single replayable event stream reprocessed by consumers	The event schema on the durable log, versioned so replays run the corrected logic
Medallion	Staged transformations from raw to business-ready tables within one platform	Schema enforcement and quality checks at each layer boundary (bronze to silver to gold)
Data Mesh	Domain-owned data products consumed by other domains	Data contracts (owner, schema, freshness SLA) each product must publish
Data Lakehouse	SQL and ML workloads reading the same underlying tables	Table format governance: schema evolution rules and ACID guarantees enforced across all writers
Semantic Architecture	Shared vocabulary referenced by other systems and contracts	Canonical model / ontology definitions that other data contracts must conform to

Architectural style splits into an interaction thread and an ownership thread that converge on a contract

Pull the last two sections together and a hierarchy emerges. Architectural style sits at the top and splits into two threads: an interaction model and an ownership model. The interaction model is what gives us architecture patterns, Lambda, Kappa, Medallion, and Data Lakehouse. The ownership model is what gives us data architecture in the Data Mesh sense, domains owning their own data. Both threads converge on the same thing: a data product or API that other domains and systems consume.

That data product or API is governed by a contract, semantic, technical, and behavioural (the quality rules, SLAs, and versioning covered under Data Mesh, and developed further in the Contracts section below), and the contract is what ultimately gets implemented: on Delta tables, in Fabric, in Databricks, or wherever the pattern lands.

Architecture patterns describe how data systems are organised. Architectural styles describe how their components interact. Contracts make those interactions explicit.

That’s the taxonomy the six patterns sit inside. Lambda, Kappa, Medallion, Data Mesh, Data Lakehouse, and Semantic Architecture were never really peers: they sit at different points in this hierarchy, which is why grouping them by category, and showing where each makes its primary decision, matters more than treating them as six interchangeable options.

The six patterns diverge because each makes its primary decision on a different dimension

Architectural style is one lens. A second, more useful one is which dimension a pattern makes its primary decision on, and that’s where the six genuinely diverge:

Pattern	Primary architectural decision
Lambda	Processing
Kappa	Processing
Medallion	Transformation
Data Mesh	Ownership
Data Lakehouse	Storage/platform
Semantic Architecture	Meaning

Seen this way, these patterns are not necessarily alternatives. They operate at different architectural dimensions and can be combined: a real enterprise architecture might combine Data Mesh, Data Lakehouse, Medallion, and an event-driven or Kappa-style pipeline, rather than choosing just one of the six.

Lambda, Kappa, Medallion, Data Mesh, Data Lakehouse, and Semantic Architecture each solve a different problem

Worth flagging up front: these six aren’t peers in the strict sense. Lambda and Kappa are processing architectures, Medallion is a data organisation pattern, Data Mesh is an organisational paradigm, Data Lakehouse is a platform and storage architecture, and Semantic Architecture is concerned with meaning itself. We group them together because they’re the patterns you reach for when designing a data platform, not because they compete for the same slot.

Lambda and Kappa make the processing decision, trading pipeline count for latency

Lambda Architecture runs batch and streaming side by side into a shared serving layer. You use it when you need both historical accuracy and low latency, for example fraud detection running next to daily BI reporting. The cost is running two pipelines that must agree with each other.

• Best when: We need both historical accuracy and low latency
• Trade-off: Two pipelines that must agree with each other
• Problem, decision, consequence: We need both historical accuracy and low latency from the same data, so we decide to run two pipelines that reconcile in a shared serving layer; the consequence is two pipelines that must be kept in sync.
• AI readiness: Useful where an AI system needs both a real-time feature and a reconciled historical view, though the dual-pipeline complexity adds latency to keeping training and inference data in sync.
• For example: a card payments provider scores each transaction for fraud in real time through the streaming layer, while the batch layer reprocesses the previous day’s settlement file to catch anything the real-time model missed. Both feeds converge in the same serving layer, so the fraud dashboard shows a live risk score alongside an end-of-day reconciliation.
• Implementation: the batch layer is typically Spark or Databricks jobs reading from S3 or ADLS; the streaming layer is Kafka feeding Flink or Spark Structured Streaming; the serving layer is a key-value store such as Cassandra or DynamoDB, or a merged view in the warehouse. The key configuration decision is how you reconcile late-arriving batch corrections against results the streaming layer has already served, usually by watermarking records or running an overwrite job once the batch catches up.

Kappa Architecture simplifies that down to one pipeline. Everything is a stream, and the event log is the source of truth. It fits clickstream analytics and anything where reprocessing logic can live inside the stream itself. The trade-off is that all your correction and backfill logic must be built into that same stream.

• Best when: Reprocessing logic can live inside the stream itself
• Trade-off: Correction and backfill logic must be built into that stream
• Problem, decision, consequence: Reprocessing and backfill logic needs to live in one place, so we decide to treat the event log as the single source of truth; the consequence is that all correction logic must be built into the stream itself.
• AI readiness: Good fit for AI systems that need to reprocess history through an updated model, since replaying the event log is exactly how you’d re-embed or re-score past events.
• For example: a ride-hailing app treats driver location and trip events as a single stream. When we need to fix a bug in the surge-pricing logic, we don’t rebuild a batch job; we replay the event log through the corrected stream processor, and the numbers catch up on their own.
• Implementation: the durable, replayable log is usually Kafka or Pulsar, processed with Flink or ksqlDB, with results landing in a serving store such as Druid or a materialised view. The key configuration decisions are the log retention window (or whether you use log compaction) and versioning the stream processing job itself, so a replay runs the corrected logic rather than the one that caused the bug.

Medallion makes the transformation decision, staging data through bronze, silver, and gold

Medallion Architecture is the bronze, silver, and gold staging model. Raw data lands, gets cleaned, then gets shaped into something business ready. It is the default inside most Databricks and Fabric lake houses today, and its main cost is the governance overhead of managing three layers instead of one.

• Best when: We want staged data quality and reuse across teams
• Trade-off: Governance overhead of three layers instead of one
• Problem, decision, consequence: Raw data needs to become business-ready without losing traceability, so we decide to stage it through progressively cleaner layers; the consequence is the governance overhead of maintaining three layers.
• AI readiness: Strong foundation for RAG because Bronze preserves raw context while Gold provides curated business entities.
• For example: a retailer’s point-of-sale data lands raw in Bronze, gets deduplicated and type-cast in Silver, then rolls up into a Gold sales-by-region table that feeds the weekly leadership dashboard.
• Implementation: the layers usually sit on Delta Lake or Iceberg tables on Databricks or Fabric, orchestrated with Databricks Workflows, Airflow, or Fabric pipelines. Bronze is append-only raw ingestion, Silver applies schema enforcement and upserts, and Gold aggregates into the star-schema tables that BI tools such as Power BI query directly. The key configuration decision is where you enforce schema: at Silver write time with constraints or leave Gold consumers to handle drift themselves.

Data Mesh makes the ownership decision, decentralising data to domains

Data Mesh decentralises ownership. Instead of one team owning all the data, each business domain owns and publishes its own data products. It is built for large organisations where a single central team cannot realistically own everything, but it only works if domains agree on shared standards. Without that agreement, you get three well-run domains that cannot be joined to each other.

• Best when: A single central team cannot realistically own everything
• Trade-off: Only works if domains agree on shared standards
• Problem, decision, consequence: A single central team cannot realistically own everything, so we decide to decentralise ownership to domains; the consequence is that domains must agree on shared interoperability standards or their data products can’t be joined.
• AI readiness: Strong if contracts and semantics are mature; weak if domains publish incompatible definitions.
• For example: at a logistics company, the warehousing domain publishes a shipment-events data product, and the finance domain publishes a cost-centre data product, each on its own release schedule, if both honour the organisation’s shared data contract standard.
• Implementation: there is no single required stack, but it relies on a shared catalogue (such as Purview, Datahub, or Collibra) and a common contract format, for example a schema registry or JSON Schema and contracts, so domains can publish independently without breaking consumers. The key configuration decision is the interoperability standard itself: what a data product must include before it is allowed to be published, for example a canonical definition, its attributes, a JSON Schema technical representation, and a data contract specifying owner, producer, consumer expectations, quality rules, SLA, versioning, and change policy.

Data Lakehouse makes the storage decision, unifying SQL and ML on one platform

Data Lakehouse merges the lake and the warehouse into one platform, usually on an open table format like Delta Lake or Iceberg, so SQL and ML workloads sit on the same foundation. Platform discipline matters more here than tooling choice.

• Best when: We want SQL and ML on one foundation
• Trade-off: Platform discipline matters more than tooling choice
• Problem, decision, consequence: SQL and ML workloads are split across separate platforms, so we decide to put both on one open table format; the consequence is that platform discipline (governance, schema evolution, ACID guarantees) matters more than tooling choice.
• AI readiness: Excellent for unified analytics and AI training workloads.
• For example: a bank runs its risk models, ad-hoc risk queries, and executive dashboards off the same Delta Lake tables, closing the old gap between a warehouse built for reporting and a separate lake built for data science.
• Implementation: the table format is usually Delta Lake, Iceberg, or Hudi on object storage such as S3, ADLS, or GCS, queried through engines like Databricks SQL, Trino, or Fabric’s SQL endpoint, with the same tables read directly by Spark or Python for ML training. The key configuration decision is table format governance: who can write to a table, how schema evolution is handled, and whether ACID transactions are enforced consistently across every writer.

Semantic Architecture makes the meaning decision, the one AI consumption depends on most

Semantic Architecture treats meaning itself as something to be engineered, not just the storage or the pipeline. Canonical models, knowledge graphs, ontologies, and business vocabularies exist so that systems, and increasingly AI agents, agree on what the data means before they agree on anything else. Its cost is the ongoing effort of maintaining a shared vocabulary across teams who’d rather just ship their own definition.

• Best when: We need systems, or AI agents, to agree on what data means, not just how it’s structured or stored
• Trade-off: Maintaining a shared vocabulary requires ongoing cross-team governance that’s easy to let lapse
• Problem, decision, consequence: A large share of enterprise data failures turn out to be semantic rather than storage, ownership, or processing failures, so we decide to make meaning itself an explicit, governed artefact via canonical models and ontologies; the consequence is an ongoing governance cost that outlives any single project.
• AI readiness: Arguably the pattern AI consumption depends on most: an agent or RAG pipeline can only reason correctly across systems if “customer” means the same thing everywhere it looks.

For example: at a financial services group, “customer” meant something different in the lending system than in the wealth management platform. A canonical model and shared business vocabulary let both systems, and the AI assistant sitting on top of them, resolve “customer” to the same underlying entity before any data ever moved.

Implementation: the canonical model usually lives in a knowledge graph or an ontology tool, such as RDF/OWL or a graph database like Neo4j, with business vocabularies maintained in a glossary or catalogue (Purview, Collibra, Atlan) that other systems and contracts reference. The key configuration decision is how strictly you enforce the canonical definitions: as a hard validation gate at publish time, or as a reconciliation layer that maps local definitions onto the canonical model after the fact.

Contracts, not infrastructure, are becoming the primary architectural boundary

Architectural styles constrain interaction. Contracts make those constraints explicit and enforceable. The Data Mesh section above already touches on this: JSON Schema, ownership, quality rules, SLA, versioning, and change policy. It’s worth generalising, because a contract isn’t just a technical schema. We’d define it at three levels.

Business contract:

Customer means an organisation with an active commercial relationship.

Semantic contract:

Customer, with attributes customerId, legalName, country, and status.

Technical contract:

{ “customerId”: { “type”: “string” } }

Schema compatibility does not guarantee semantic compatibility. Two domains can agree perfectly that customerId is a string and still disagree completely about what a customer is. That’s precisely where canonical models, business definitions, ontologies, and taxonomies fit, alongside the data quality rules, ownership, SLAs, versioning, and change management already covered under Data Mesh. In short: schema is not the same as meaning. A contract is meaning, structure, behaviour, and expectations together.

Push that further and the boundary itself shifts: contracts are becoming the primary architectural boundary in data architectures, not the underlying infrastructure. Today:

• APIs are contracts
• Events are contracts
• Data products are contracts
• Agent interfaces are contracts

The architecture is increasingly defined by contracts rather than physical integration.

AI architecture is increasingly a governance problem disguised as a technology problem

Architectural style, primary decision, and contracts all point to the same conclusion: these six patterns are composable decisions, not mutually exclusive choices. A real enterprise architecture typically combines several of them rather than picking just one.

For example: a Data Mesh sets domain ownership and has each domain publish its own data products. Those products can land in a Data Lakehouse, giving combined SQL and ML access on one platform. Within that Lakehouse, a Medallion staging model takes each domain’s raw data through bronze, silver, and gold. And where a domain’s product needs both historical accuracy and low latency, that staging can be fed by a Kappa-style stream instead of a separate batch job.

Or, for a different use case, the same six building blocks combine differently: Data Mesh for ownership, Data Lakehouse for the storage platform, Medallion for staging, an event-driven architecture for interaction, data contracts to make it all enforceable, and a Semantic Architecture canonical model underneath so every domain agrees on what the data means, layered together rather than choosing one pattern in isolation.

Architecture patterns are composable decisions, not mutually exclusive choices, but that observation alone undersells what’s changed. Analytics architectures were optimised for human consumption; AI architectures must optimise for machine reasoning, and machine reasoning only works when the semantics are explicit. Explicit semantics require contracts, and contracts only hold up if someone governs them: who owns the definition, who can change it, and what happens when they do. Follow that chain through and AI architecture turns out to be a governance problem wearing a technology disguise.

That’s the real shift we’ve been building towards in this paper: AI does not increase the value of storage, processing, and integration. It dramatically increases the value of meaning, contracts, and governance. The six patterns above are still the right building blocks; what’s changed is which of them now carries the weight.