Showback vs Chargeback for Kafka Platforms

Stéphane Derosiaux September 10, 2026 7 min read

Showback and chargeback are the two FinOps models for returning the cost of a shared platform to the teams that consume it. Both start from the same allocation: usage metered per consumer and mapped to an owner. They differ in what happens next. Showback reports each team's share and leaves the money where it is. Chargeback moves the money, so the consuming team's budget pays. For a shared platform like Apache Kafka, where one cluster serves hundreds of applications and the cloud invoice shows a single line, the choice decides whether cost visibility turns into changed behavior.

What showback does

Showback is an informational model. The platform team computes what each application, team or business unit consumed, prices it with unit costs, and publishes the result. Budgets do not move. A payments team sees that its topics account for 38 percent of Kafka spend this month, but the platform cost center still pays the invoice.

Showback is the usual first step. It needs no agreement with finance about internal transfer pricing, so it can ship in weeks, and it tolerates imperfect data: a report with a large "unlabeled" row is still useful, whereas an invoice with one is contested. The platform team also gets to check its unit costs against the real bill before anyone is charged on them.

The limit of showback is that a number nobody pays for is easy to ignore. Teams read the report, agree the waste is real, and move on to their own roadmap.

Two things decide whether a showback gets acted on. The first is the recipient: a report sent sideways to the engineers who created the topics competes with their roadmap and loses, while the same report sent to the budget owner for those applications becomes an item in a budget review. The second is the unit. On a cluster bought upfront or on committed capacity, a dollar figure is a fiction until renewal. Percentage of cluster capacity and partitions or GB reclaimed are the numbers a team can move this quarter, and the dollar value is what those units are worth at the next resize.

Showback is also a legitimate end state, not only a stepping stone. A platform run as a centrally funded shared service, whose team sees itself as an adviser to product teams rather than a supplier to them, can keep the cost and use the report as guidance: this is what your usage looks like, and this is what you could do about it. Chargeback becomes necessary when the platform is expected to fund itself, or when consumption grows faster than a central budget can absorb.

What chargeback does

Chargeback is a financial model. The same allocated cost becomes an internal charge against the consuming team's budget, through a cross-charge, a journal entry or an internal invoice. The FinOps Framework lists it under the Invoicing & Chargeback capability, in the domain that manages the FinOps practice itself.

Chargeback changes incentives because the team that can retire a topic is now the team whose budget shrinks when it does. On a Kafka platform that means a product team has a reason to drop a 48-partition topic to 6, cut 30-day retention on a topic consumed within an hour, or delete the derived topic a filter-only stream job produced.

Chargeback also demands better data. Every disputed line item becomes a conversation between engineering and finance, so the allocation has to be defensible: every topic and service account mapped to an owner, unit costs traceable to the provider price list, and the total reconciled against the actual invoice.

Showback vs chargeback: same allocation, different consequences

What both models need from Kafka

Neither model works without allocation, and Kafka does not provide it out of the box. The broker exposes bytes in and out per client and per topic, partition counts and log sizes, but nothing that says which team a topic or a service account belongs to. Three inputs are required either way:

  1. Metered usage per cost axis. Storage as byte-hours, partitions as partition-hours, ingress and egress as bytes, and Kafka Connect as task-hours where connectors run. Managed providers such as Confluent Cloud expose some of these through a metrics API. On self-managed or MSK clusters a proxy or an agent has to capture ingress and egress per service account.
  2. Ownership metadata. Labels on topics, applications and service accounts for team, cost center and environment. The share of unlabeled spend is the first number to drive down.
  3. Unit costs. A price per GB-hour of storage, per partition-hour, per GB of ingress and egress, taken from the provider's price list or from an internal model for on-premises clusters.

Unit costs differ by cluster type. For Confluent Cloud they can be derived from the billing API or the invoice, and they move as the cluster grows. For on-premises Confluent Platform or Apache Kafka clusters they are a modelled internal rate, stable month to month and revised at renewal. Organisations that build a chargeback on the cloud billing API alone end up with allocation for their managed clusters and nothing for the on-premises ones, which is usually where the older and larger topics live. The allocation layer has to sit above both.

A minimal showback query over metered data:

-- Monthly showback grouped by the team label on each topic
SELECT
  t.team_label                                        AS team,
  SUM(u.byte_hours / POWER(1024, 3)) * c.storage_rate   AS storage_usd,
  SUM(u.partition_hours) * c.partition_rate             AS partition_usd,
  SUM(u.bytes_in  / POWER(1024, 3)) * c.ingress_rate    AS ingress_usd,
  SUM(u.bytes_out / POWER(1024, 3)) * c.egress_rate     AS egress_usd
FROM topic_usage u
JOIN topic_metadata t ON t.topic = u.topic AND t.cluster = u.cluster
JOIN cluster_costs  c ON c.cluster = u.cluster
WHERE u.period = '2026-08'
GROUP BY t.team_label, c.storage_rate, c.partition_rate, c.ingress_rate, c.egress_rate
ORDER BY storage_usd + partition_usd + ingress_usd + egress_usd DESC;

The same query feeds chargeback once finance signs off on the rates and the mapping. Tools like Conduktor produce this table directly: Chargeback in Console meters the cost axes per topic, groups them by application, service account or label, and exports the result as CSV for finance.

When to move from showback to chargeback

Showback is the default starting point. Chargeback is worth the added process when three conditions hold: label coverage is high enough that the unlabeled row is small, the monthly total reconciles with the invoice within a tolerance finance accepts, and teams already have self-service controls to act on their own resources. Charging a team for topics it cannot retire or rightsize without a ticket produces disputes, not savings.

Moving to chargeback also changes what a label is. Under showback a wrong label is an untidy report. Under chargeback it moves money, so a team that can edit its own labels can move its cost to another cost center. Before the switch, restrict label edits to resource owners with an explicit metadata permission, keep an audit trail, and fix the set of label keys that count for allocation.

A full move is not required. A hybrid is a valid end state: showback for most teams, chargeback for the few large consumers whose usage dominates the bill, or chargeback only on the axes that are cleanly measurable, such as partitions and storage.

Summary

Showback and chargeback are the same allocation with different consequences. Showback makes Kafka cost visible quickly and safely, and is enough to start conversations about partition counts and retention. Chargeback makes the cost someone's problem, which is what finally changes behavior on a shared platform, but it demands complete ownership metadata, defensible unit costs and self-service controls for the teams being charged. Most Kafka platforms start with showback, use it to raise label coverage and validate rates, and move the largest consumers to chargeback once those foundations hold. See Kafka FinOps for how this fits the wider Inform, Optimize and Operate loop.

For a vendor-aware walkthrough, see Kafka cost allocation and chargeback.

Sources and References