Confluent Freight trades latency for lower replication cost

Replicating every write across availability zones can make network traffic a large part of a streaming system's infrastructure cost. Confluent Freight changes that arrangement by writing directly to object storage and accepting longer latency. Its appeal depends on whether a workload needs fast delivery of each event or mainly needs sustained movement of a large volume of data.

Confluent's February 3 release notes make Freight generally available on AWS. The launch explanation connects the economics to a direct-write mode in Kora, Confluent's cloud-native engine. This is a managed service architecture, not a new Apache Kafka broker configuration released upstream.

I find Kafka useful because retained history can feed independent consumers and support replay. That does not mean every such workload needs the same delivery latency. Freight is interesting because it makes a different latency requirement an explicit basis for selecting the service.

Direct writes change the replication path

Confluent says the direct-write mode sends data to object storage such as S3, bypassing local storage and avoiding replication on Kora brokers. Object storage takes the place of the expensive broker-to-broker replication path described in the announcement.

The tradeoff is explicit. Confluent compares sub-100-millisecond latency in its other cluster types with up to a second or two for Freight. These are the supplier's descriptions of the service design, not benchmark results for an arbitrary application.

That interval can be acceptable for observability pipelines or batch-oriented ingestion while being unsuitable for a decision that must react to an individual event immediately. The distinction concerns the application's required delay. Calling both workloads streaming does not make their latency constraints identical.

The architecture also makes the source of a claimed saving understandable. It removes a category of inter-zone broker replication traffic instead of relying only on cheaper compute. That is a different economic mechanism from changing the amount of capacity assigned to the same replication arrangement.

It would be misleading to translate the announcement into a general claim that object storage removes all distributed-system costs. Freight still provides a managed service with its own execution, storage, and networking behavior. The published explanation identifies specific costs the design aims to avoid.

The choice therefore belongs at the workload boundary. An application that values retained events and throughput can benefit from Kafka-compatible interfaces without requiring the fastest cluster type. The service can price that different requirement through a different internal storage path.

Zone-aware clients remain part of the cost model

Freight also uses Fetch from Follower. Confluent describes retrieving from followers instead of leaders across availability zones. It ties removal of cross-zone traffic costs to clients configured for zone-aware production and consumption.

That condition matters because a managed service cannot infer every client's intended locality from the existence of a cluster. The client configuration and its placement affect which network path carries the data. The internal architecture and the surrounding deployment therefore cooperate to produce the advertised result.

The same consideration applies to replay. A consumer reading older retained data is still moving bytes through a network path. The fact that consumption is non-destructive does not make the placement of that consumer irrelevant to cost.

My view of Kafka begins with the partition log, but its economics depend heavily on where producers and consumers run. Freight makes that dependence visible. A cluster selected for a cost model needs clients configured to participate in that model.

The announcement's percentage savings should be read with those conditions intact. The release notes advertise up to 80 percent savings against self-managed Kafka, while the launch article discusses up to 90 percent and early-access customer infrastructure results. Those figures use supplier-defined comparisons and should not become a guaranteed reduction for every deployment.

A useful explanation can state the mechanism without choosing the largest percentage as a universal result. Direct object writes reduce a replication cost category. Zone alignment reduces another traffic category, subject to the documented client configuration. The resulting bill depends on the workload and its actual deployment.

Autoscaling addresses unused capacity separately

The release notes say Freight scales up to 152 elastic Confluent units. The launch article describes a range beginning at two eCKUs and returning downward as demand falls. This is a capacity management mechanism separate from direct storage writes.

A statically provisioned cluster must reserve enough capacity for the demand it intends to serve. If demand is intermittent, some of that capacity remains unused between peaks. Autoscaling changes how much provisioned service capacity follows the workload.

Confluent presents this as a second source of savings. It should not be conflated with the elimination of inter-zone replication traffic. A deployment could have little idle capacity while still paying heavily for network movement, or have modest network charges while reserving much more capacity than it uses.

The eCKU range describes the managed service's scaling interface. It is not a recommended number of self-managed Kafka brokers. Translating it directly into broker count would require a resource and workload relationship that the launch does not establish.

Private Network Interface supplies the connectivity path

The release introduces Freight alongside Private Network Interface support. The release notes describe attaching an Elastic Network Interface from the customer's AWS account to a network service in Confluent's AWS account. Freight uses that ENI to provide access from the customer's environment.

This adds another part to the service definition. The cluster type determines the data path and latency tradeoff. PNI determines the supported connectivity arrangement for reaching that cluster at launch.

The announcement emphasizes avoiding some of the management difficulties associated with VPC peering. That is a statement about the supplied service interface, not a reason to assume the customer's network configuration disappears. Access still has an identified attachment and account relationship.

Freight's GA release thus offers a particular combination. Direct object-storage writes reduce reliance on cross-zone broker replication, while elastic capacity addresses idle provisioned resources. Zone-aware clients and the PNI connection remain part of the deployment. The application accepts the documented longer latency in exchange for the service's different cost structure.