Files
kong-k8s-platform/kafka-topology
Stéphane Tailland b62b92fe1a Add the procurement topic and Supply's write access to it
reorder.requested and its answer (confirmed/rejected) share the topic, keyed
by the reorder id, so ordering between the ask and the answer holds the way it
does for a product's own facts on classic-models.catalog.

Supply both writes and reads this topic — one service, two capacities, not a
separate procurement identity, per the 2026-08-31 decision.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 16:17:05 +02:00
..

Kafka topology

Platform-owned. Topics and accounts on the shared Kafka cluster are administered here, not by the teams that use them.

That is the same reason gateway defaults are here: an ACL is not a team's decision to make about itself. A team that declares its own KafkaUser grants its own permissions, and a team that declares its own KafkaTopic sets a partition count and a retention that the cluster then has to live with. Both are platform decisions, taken with a view of the whole cluster.

It is also why this is not self-service, and should not be mistaken for it. See "Self-service" below.

What lives here

classic-models.yaml the classic-models estate: three topics, one producer account, one consumer account

The cluster is not here — infra-kafka is a generic, reusable Strimzi deployment and names no estate. This repo says who may publish what on it.

The events are not here either: their contract belongs to the application that raises them, in classic-models-api/docs/DOMAIN_EVENTS.md. This repo grants access; it does not define meaning.

Two things that bite

Every CR goes in the operator's namespace. Strimzi runs with watchAnyNamespace=false, so a KafkaUser or KafkaTopic created anywhere else is ignored silently — kubectl apply says created, kubectl get shows it, and it never gets a status, a Secret, or a line in the operator's log. It looks exactly like one still being reconciled.

Grant one direction, on one prefix. A producer that can also read every topic exfiltrates every other application's data if it is ever compromised; a consumer that can write can raise an event someone else acts on.

Self-service, when it comes

Not by letting teams declare CRs here or in their own repos. Through an event gateway, which virtualises topics so a consumer is given a contract rather than a broker address and an ACL, and through the developer portal, which socialises those topics the way it already socialises the REST APIs.

Until that exists, this directory is the request queue: a team asks, the platform team writes the entry.