# Kafka Guardrails Gate. Templates Guide.

Once you let application teams create their own Kafka topics and connectors, you want [self-service provisioning](https://www.conduktor.io/blog/federated-governance-solve-the-speed-vs-control-dilemma) without a free-for-all. So you reach for a way to enforce your standards. Every option below works. None of them is the whole story.

## How Teams Enforce Kafka Standards

**A wiki page.** Your naming convention and recommended configs live in Confluence. Enforcement is social: people follow it when they remember it, and the page goes stale the week after it's written.

**Ticket-based provisioning.** You turn off `auto.create.topics.enable` and route every topic through a request. The platform team creates each one by hand. The human is the policy. Safe, and exactly the bottleneck self-service provisioning was supposed to remove.

**A script.** A shell wrapper around `kafka-topics.sh`, or something on the AdminClient API that regex-checks the name and exits non-zero when it doesn't match. It runs in CI, catches the obvious mistakes, and is owned by the one person who wrote it.

**Topics as code.** Tools like [topicctl](https://github.com/segmentio/topicctl), kafka-gitops, and Jikkou let you define topics in YAML and apply every change through a reviewed pull request. Git becomes the source of truth. It's the most sophisticated option here, and a real improvement over a ticket queue.

Each of these does the same thing the moment something is wrong. The script exits 1. The pull request gets rejected. The ticket bounces back with a comment. They all answer one question, *is this allowed?*, and they all answer it the same way: no! Enforcement is a gate. Its whole job is to draw a boundary and stop you at it, and saying no was never the hard part.

## The Developer Still Has to Guess

> 🚫 *"We've got policies in place, so our cluster is governed."*

Ninety percent of the time, the developer on the other side of that gate isn't malicious or careless. They're shipping a new service, they need a topic, and they're not a Kafka expert.

So they guess. They pick six partitions because the example in the docs used six. They leave `cleanup.policy` on its default because they aren't sure what compaction would change. They submit, and your gate rejects it. The only thing they've learned is that this particular combination of settings doesn't pass.

The information that would have gotten the topic right isn't secret. It's just out of reach. Which workloads want 24 partitions, when [compaction](https://www.conduktor.io/glossary/kafka-log-compaction-explained) beats deletion, which `min.insync.replicas` goes with which [replication factor](https://www.conduktor.io/glossary/kafka-replication-and-high-availability): that lives in a couple of experts' heads and a wiki nobody opens. A gate checks the developer's answer. It was never built to supply one.

So stricter rules don't help. The developer is still guessing, and a tighter gate just rejects the guess sooner.

## What a Configuration Template Does

The other half isn't a stronger boundary. It's a better default. We built it into [Conduktor Console](https://www.conduktor.io/console) as configuration templates.

A configuration template encodes the platform team's decisions once and pre-fills them into the create form. Instead of the cluster's generic defaults, the developer starts from values already correct for the workload and changes only what's specific to their case.

Prefer to watch? The two-minute version of the idea. [See it in the demo center →](https://www.conduktor.io/product-demos)

## Topics: The Partition Count You Set Once

Take a high-throughput topic. A [topic template](https://docs.conduktor.io/guide/reference/self-service-reference#topictemplate) seeds 24 partitions, replication factor of three, a delete cleanup policy, seven-day retention, and `min.insync.replicas` of two. It also seeds your naming convention and the governance labels you expect, with `{{placeholder}}` values the developer fills in.

Most of those a developer could eventually look up. The partition count is different. Twenty-four [partitions](https://www.conduktor.io/glossary/kafka-partitions-explained) is a deliberate capacity decision about how much the topic can run in parallel, and it's one of the few topic settings that's painful to change after the fact. A template makes that call once, at creation, so it's correct from the start instead of fixed after an incident.

The template in the Create Topic form, from YAML to a filled-in form. [See it in the demo center →](https://www.conduktor.io/product-demos)

## Connectors: Three Settings That Need an Expert

Topics are the gentle case. Connectors are worse.

Open the configuration for a JDBC sink connector and you're looking at dozens of properties. To a developer who isn't a [Kafka Connect](https://www.conduktor.io/glossary/kafka-connect-building-data-integration-pipelines) expert, that blank form is where self-service provisioning quietly dies and the tickets start.

But most of those properties aren't the hard part. A handful are: whether `insert.mode` is `upsert` keyed on the record key, so reprocessing a record updates the row instead of duplicating it; whether `auto.create` and `auto.evolve` are on, so the table and its schema track the topic. Those are the decisions that take real Connect experience to get right, and they're invisible to someone seeing the form for the first time.

A [connector template](https://docs.conduktor.io/guide/reference/self-service-reference#connectortemplate) makes those decisions in advance. The developer picks the connector, starts from the vetted template, and supplies the only part they know better than the platform team: the source topic, and where the data is going. The expertise is already in the form. They fill in the two fields that are theirs.

The JDBC sink template in the connector wizard, dozens of properties down to a few. [See it in the demo center →](https://www.conduktor.io/product-demos)

## Pair the Policy With the Template

[Self-service provisioning](https://www.conduktor.io/blog/governed-kafka-self-service) needs both halves. A gate without guidance leaves teams to learn the rules by failing. Guidance without a gate is a suggestion teams can ignore. Together, the policy enforces the same standard the template recommends.

Pairing the two pays off three ways:

- **Governance that guides, not just gates.** Policies block what teams shouldn't do, and templates point them at what they should.
- **Expertise that compounds.** Your Kafka know-how becomes a reusable asset every new team inherits, instead of tribal knowledge stuck in a few people's heads.
- **A platform team that scales.** The expert decisions get made once, so developers spend their time building and misconfigurations drop.

At Conduktor, [ResourcePolicies](https://docs.conduktor.io/guide/reference/self-service-reference) enforce the boundary on topics, connectors, schemas, and application groups, blocking anything that violates the rules on create or update. Configuration templates supply the guidance, pre-filling the create form with the defaults your experts would have chosen. The policy says where the edge is. The template puts the developer in the right place to begin with.

Your guardrails were only ever half the story. They tell teams what they can't do. It's worth being just as deliberate about telling them what they should.