Which outbox table columns does Debezium's EventRouter SMT read, and how does it pick the topic and key?

## Why the router exists Raw change events publish your table schema. Every consumer then depends on column names you wanted to be free to rename, and on rows that mean nothing outside your service. An outbox table inverts that: the service writes a *designed event* into a table inside the same local transaction as the business change, and the connector captures that table instead of the business tables. The router is the piece that converts a captured outbox row into a message that looks nothing like a row. ## The conventional shape A minimal outbox table has five columns. `id` is a unique event identifier, typically a UUID. `aggregatetype` names the kind of thing the event is about — `Order`, `Customer` — and is the routing dimension. `aggregateid` identifies the specific instance, and becomes the message key. `type` names the event itself — `OrderCreated`, `OrderCancelled`. `payload` holds the event body, usually JSON. None of these names are mandatory. `table.field.event.id`, `table.field.event.key`, `table.field.event.type`, `table.field.event.payload` and `table.field.event.timestamp` each point the router at whichever column plays that role, which matters when you are retrofitting an existing table or when your schema conventions forbid all-lowercase compound names. ## Routing `route.by.field` names the column whose value selects the topic; it defaults to the aggregate type column. Its value is interpolated into `route.topic.replacement`, whose template expands the routed value into a topic name. The practical effect is one captured table fanning out into one topic per aggregate type, which is usually the granularity consumers want to subscribe at: a fulfilment service consumes order events without also receiving every customer-profile change. A subtlety candidates miss: the routed topic must exist or auto-creation must be permitted, and because routing is data-driven, inserting a new aggregate type creates a new topic at runtime. That is a governance question, not just a config one. ## Keys, ordering and deduplication The key column's value becomes the record key. Since a Kafka producer partitions by key, every event for aggregate `order-42` lands on the same partition, and the broker preserves order within a partition — so consumers see that order's events in the sequence the service wrote them, without any global ordering guarantee across aggregates. Choosing the aggregate id as the key is therefore not cosmetic; it is the entire ordering story. Delivery is at-least-once, so consumers must tolerate a repeat. The router propagates the outbox row's identifier as a message header exactly so a consumer can keep a seen-ids set and discard duplicates cheaply, without parsing the payload. ## Extra fields `table.fields.additional.placement` projects further outbox columns into the message. An entry names the column, whether it goes into the value or into a header, and optionally the alias to use — putting the event type into a header, for example, lets a consumer filter or dispatch without deserialising the payload at all. Trace identifiers, tenant ids and a schema version are the columns teams most often add. ## Insert-only semantics and cleanup The router is built for insert events. The service inserts an outbox row and never updates it; many teams delete the row in the very same transaction, because log-based capture reads the transaction log rather than the table, so the insert is captured even though the row never becomes visible to a query — and the table stays empty. On engines where that trick does not apply, a periodic purge job keeps the table small. Either way, updates to outbox rows are not part of the model, and a pipeline that produces them is a design smell to raise rather than a case to configure around. ## Operating notes Capture the outbox table only, not the business tables, or you have published the schema you were trying to hide. Watch that a low-traffic outbox does not leave the capture position stalled behind an idle log. And treat the payload as a contract with its own versioning story: the router happily ships whatever string the service wrote, so nothing in this transform stops a producer from breaking every consumer in one deploy.