Updated November 2026: We have restructured this August 2023 post, corrected the Kafka adoption statistic (the Apache Kafka project cites more than 80% of the Fortune 100), added Confluent Stream Sharing’s current limits from the Confluent Cloud documentation, and replaced the 2023 event registration notice with a link to the event recap.
Apache Kafka has become the standard way for organisations to move data internally: the Apache Kafka project says more than 80% of all Fortune 100 companies use it. Once events flow freely between internal teams, the next step is to extend the same data movement framework to external partners and close collaborators.
Building data products from external data sources raises important questions about governance, data security and data policy. It is also a frontier with great potential for companies that already run Kafka internally, because the same topics, schemas and clients can serve partners as well as internal teams.
A data product is a stream of data that a team owns, documents and publishes for others to consume, with a defined schema, quality expectations and access rules. In a streaming platform, that usually means a well-governed Kafka topic rather than a one-off export.
Kafka and data streaming keep gaining popularity because of the range of use cases they support. One example is an online grocery retailer that relies on Kafka for its operations, with millions of events streaming through its system every day. That event data helped it offer deliveries in under 15 minutes as a premium subscription feature.
The service grew out of data gathered from robots in its warehouse, a physical picture of data streaming: groceries flow along conveyor belts while events flow through topics. Examples like this encourage more companies to treat their event streams as data products they can build on and share.
Confluent Stream Sharing exchanges Kafka topic data between separate organisations from Confluent Cloud. A data provider invites a recipient by email; once the recipient accepts, they can consume the shared topic directly with a Kafka client, using an existing Confluent Cloud organisation or a new account.
With Stream Sharing, teams can:
Confluent documents some limits that matter when you design a sharing model:
| Area | Current Stream Sharing behaviour |
|---|---|
| Invitations | Recipients are invited by email only |
| Throughput | 10 MB per second per share by default; Confluent can adjust it on request |
| Cluster types | Basic, Standard and Dedicated clusters; Enterprise clusters are not supported |
| Cluster Linking | Not supported; data is shared directly from the provider’s cluster |
| Private networking | Public internet, AWS PrivateLink, Azure Private Link and Google Cloud Private Service Connect; provider and recipient must use the same cloud for private endpoints |
| Access control | Wildcard principals on topics also apply to recipients, so review ACLs before sharing |
If you run Apache Kafka yourself rather than on Confluent Cloud, you can build a similar model with dedicated partner-facing topics, per-partner ACLs and quotas, mTLS or SASL authentication and a schema registry. Our guide to protecting your Kafka cluster covers the security side.
These guides go deeper into the ideas in this post:
If you want help designing governed, shareable Kafka streams, talk to OSO’s Kafka engineers.
Key takeaway: Treat shared Kafka streams as data products with owners, schemas and access rules; Confluent Stream Sharing is one managed way to share topics with partners, within documented throughput and cluster limits.
Sharing real-time data across company boundaries. Most large organisations already stream data internally with Kafka, so the next step is giving partners governed access to the same event streams as data products.
A Confluent Cloud feature that shares Kafka topics with users in other organisations. Recipients are invited by email and, once they accept, consume the shared topic directly with a Kafka client.
Confluent documents a default limit of 10 MB per second per share, email-only invitations, support for Basic, Standard and Dedicated clusters but not Enterprise clusters, and no sharing through Cluster Linking.
A data product is a stream a team owns and publishes for others, usually a Kafka topic with a defined schema, documentation, quality expectations and access rules.
Yes. With self-managed Kafka you can create partner-facing topics and secure them with authentication, per-partner ACLs, quotas and enforced schemas, though you run the governance and onboarding yourself.
Talk to OSO's Kafka engineers about designing governed, secure Kafka data products you can share with partners and internal teams.
CONTACT US