---
type: "article"
title: "You will need more than a schema registry"
summary: "Most teams I talk to already have a schema registry e.g Confluent, Apicurio, Glue, Azure, GitHub. A registry is a good idea. It stops you publishing garbage at runtime. It versions the contract. Producers and consumers can agree on a shape.\nThen I ask who consumes OrderPlaced.\nSilence. Or a Slack thread. Or someone who left six months ago.\nThe registry will tell you the schema is valid. It will not tell you the architecture. It does not know the domain. It does not know the team. It does not know that payments still reads a field you were about to delete. It does not know the ADR that said we would never put PII on that event. It is a lock on the door. It is not a map of the building.\nI used to think this was a documentation problem. Put the schema in Confluence. Draw a diagram in Miro. Maybe a spreadsheet of owners. That lasts until the next deploy. The registry stays current because the pipeline forces it. The wiki does not.\nWhat we actually need is a catalog of the architecture, with the schemas attached. Domains, services, messages, owners, decisions, versions. The registry stays the source of the contract. The catalog is where that contract sits in the system you actually run. Humans can browse it. Agents can query it. Nobody has to remember.\nIf you already have a registry, keep it. The missing piece is everything around the schema: who produces, who consumes, what breaks, and who to talk to. That is the catalog.\nI have been building EventCatalog around that idea. The registry integrations exist because the schemas already live somewhere. The point is not to replace the registry. It is to stop pretending the registry is the architecture."
newsletter: "David Boyne"
newsletter_handle: "boyney123"
newsletter_url: "https://usecommune.com/n/boyney123"
author: "David Boyne (@boyney123)"
published: "2026-08-27T15:52:18.000Z"
canonical_url: "https://usecommune.com/n/boyney123/a/you-will-need-more-than-a-schema-registry"
markdown_url: "https://usecommune.com/n/boyney123/a/you-will-need-more-than-a-schema-registry.md"
chat_url: "https://usecommune.com/n/boyney123/a/you-will-need-more-than-a-schema-registry/chat"
source_url: "https://boyney123.substack.com/p/you-will-need-more-than-a-schema"
body_source: "imported"
likes: 2
replies: 2
body_words: 296
---

# You will need more than a schema registry

Most teams I talk to already have a schema registry e.g Confluent, Apicurio, Glue, Azure, GitHub. A registry is a good idea. It stops you publishing garbage at runtime. It versions the contract. Producers and consumers can agree on a shape.

Then I ask who consumes `OrderPlaced`.

Silence. Or a Slack thread. Or someone who left six months ago.

The registry will tell you the schema is valid. It will not tell you the architecture. It does not know the domain. It does not know the team. It does not know that payments still reads a field you were about to delete. It does not know the ADR that said we would never put PII on that event. It is a lock on the door. It is not a map of the building.

I used to think this was a documentation problem. Put the schema in Confluence. Draw a diagram in Miro. Maybe a spreadsheet of owners. That lasts until the next deploy. The registry stays current because the pipeline forces it. The wiki does not.

What we actually need is a catalog of the architecture, with the schemas attached. Domains, services, messages, owners, decisions, versions. The registry stays the source of the contract. The catalog is where that contract sits in the system you actually run. Humans can browse it. Agents can query it. Nobody has to remember.

If you already have a registry, keep it. The missing piece is everything around the schema: who produces, who consumes, what breaks, and who to talk to. That is the catalog.

I have been building EventCatalog around that idea. The registry integrations exist because the schemas already live somewhere. The point is not to replace the registry. It is to stop pretending the registry is the architecture.

***

## Discussion (2 replies)

Numbering shows the reply tree: `2.1` is a reply to `2`. Message text is reproduced verbatim as posted.

### 1. Kin Lane (@kinlane) - 2026-08-27T16:06:00.162Z

Yes you will!

### 2. Fran Mendez (@fmvilas) - 2026-08-27T16:08:44.178Z

Oh yeah my friend! Unless something is enforced, it's just good will.

I spent my last years at AsyncAPI saying, repeating, and advocating that AsyncAPI should not be seen as a documentation or as a side artifact. It has to become a configuration file. The code has to read it and enforce it. Otherwise, it's going to end up in the trash and devs will hate it because they see no purpose in maintaining something just for docs.