Event streaming requirements checklist

Agree these requirements before choosing a self-hosted streaming platform, with how to verify each one and the questions that separate Kafka, Pulsar, NATS and RabbitMQ.

Book a callTalk to us
On this page

How to use this event streaming requirements checklist

Agree the requirements before you pick a broker. A team choosing or rebuilding an event backbone that must run in its own data centers or cloud accounts needs to settle what the platform has to do, then test each candidate against that list. The checklist below is organized as functional, security, integration, operations and compliance requirements. Each item names the question to answer and the evidence to collect, whether that is a setting in the project's documentation, a test in a proof of concept, or a conversation with the team that will run the cluster. Platform choice between Apache Kafka, Apache Pulsar, NATS and RabbitMQ comes second, once the throughput, ordering, delivery and tenancy needs are written down.

Treat the checklist as a starting point to adapt, not a scoring sheet. Weights and pass marks invented before the workload is understood tend to favor whichever product the team already knows. Expect some items to be irrelevant for your case and others to be missing, such as a specific replay window for an audit team or a required connector to a mainframe. Vendor and community claims should be checked against the project's own documentation, including the release notes for the version you intend to deploy. For example, the Kafka upgrade notes set requirements, such as KRaft mode in 4.x, that change the operating plan. Where a claim matters to a control, prove it in a proof of concept under your own network, identity and storage conditions before it goes into the design.

Which functional requirements decide the platform

This table lists the functional requirements that most often separate Kafka, Pulsar and NATS during selection, with why each matters and how to verify it. Read each row as a question to answer with your own message sizes and workloads before you shortlist platforms. The main takeaway is that vendor claims about throughput and ordering mean little until you test them against your traffic pattern.

RequirementWhy it mattersHow to verify
Throughput and peak ratesAverage load hides the bursts that cause consumer lag, broker saturation and dropped producer sends.Measure average and peak messages per second and bytes per second per producer, then load test with your own message sizes and key distribution.
Retention period and storage growthRetention sets disk capacity and replication cost, and audit or replay needs often push it well beyond the default.Write down required retention per topic, multiply by daily volume and replication factor, and confirm how storage grows with each platform's broker or bookie model.
Ordering scopeOrdering guarantees differ by unit: Kafka orders within a partition, Pulsar orders within a topic or subscription, and NATS JetStream orders within a stream subject.Define which entity must stay in order (account, order ID, device), then test that key-based routing keeps related events in sequence under rebalancing.
Delivery guaranteesAt-most-once, at-least-once and effectively-once outcomes depend on producer settings and consumer idempotency, not only on the broker.Specify the guarantee each consumer needs, then test broker failover and consumer crashes to observe duplicates and losses against that target.
Replay needsConsumers that rebuild state, reprocess after a bug or backfill a new service need historical reads from a chosen point.List replay scenarios and required lookback. JetStream consumers can replay from the start, the latest message, a sequence number or a point in time; confirm equivalent offset or cursor behavior in Kafka and Pulsar with each project.
Queue versus log semanticsWork queues that distribute tasks differ from event logs that many consumer groups read independently, and the wrong fit causes awkward workarounds.Map each use case to competing consumers or independent readers, then confirm how each candidate supports shared subscriptions and per-consumer offsets.
Protocols and client supportSystems may publish with the Kafka API, AMQP or MQTT, and each protocol narrows which clients, devices and bridges you can use.Inventory producers and consumers by protocol and language, then confirm native support or bridge components for each. Check NATS Tier 1 and Tier 2 client coverage for your languages.
Multi-tenancy and isolationShared clusters need separation of teams, quotas and credentials so one tenant cannot starve or read another.Define tenants, quotas and topic naming rules, then test authentication and authorization boundaries and per-tenant limits under load.

Security requirements to agree before procurement

Security decisions shape the platform choice more than most teams expect, because authentication, authorization and key handling differ sharply between Kafka, Pulsar, NATS and RabbitMQ. The cards below cover the controls to settle in writing before a shortlist is made, with the question to put to each vendor or partner and the evidence to request.

Client authentication options

Decide which identities brokers accept before choosing the platform. Kafka authenticates clients, brokers and tools with SSL or SASL, and its documented SASL mechanisms are GSSAPI (Kerberos), PLAIN, SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Ask whether the team can issue short-lived credentials from your identity provider, and whether services can authenticate with client certificates. For Pulsar, NATS and RabbitMQ, confirm the supported token, certificate and OIDC options in their current documentation. Request a written list of mechanisms per client type, including human tools and batch jobs.

Encryption in transit and at rest

Kafka encrypts traffic between clients, brokers and tools with SSL/TLS, but security is optional, so clusters can run unsecured or mix secured and unsecured listeners. Require that every production listener uses TLS and that plaintext listeners are disabled. Ask who manages certificate issuance, rotation and revocation, and how broker-to-broker and replication traffic is covered. Disk encryption for log segments, snapshots and backups is a separate control that most platforms leave to the operator, so ask the team to state which layer provides it and request the configuration used.

Authorization and ACL behavior

In Kafka KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so an unplanned default can either lock out services or open topics too widely. Ask how topic, consumer group and transactional ACLs are modeled per team, who approves changes, and how ACLs are reviewed. For the other platforms, confirm whether authorization is per namespace, tenant or account, and whether it is enforced at the broker.

Audit logging of administrative and data access

Record who created or changed topics, ACLs, users and certificates, and who consumed or produced on sensitive topics. Authorization decisions and administrative actions should reach a log store that the security team controls, with retention that matches your audit obligations. Ask the team which events are logged by default, which need configuration, and whether logs include client identity and source address. Where AI or regulated workloads are involved, the EU AI Act sets log retention expectations for high-risk systems, so confirm whether any streamed data feeds such a system before setting retention.

Client credential and secrets handling

Client passwords, SCRAM credentials, keystores and tokens tend to end up in configuration files and CI variables. Agree that secrets come from a dedicated vault or the platform's secret store, that they rotate on a schedule, and that revoking one client does not require a cluster restart. Ask how credentials are provisioned for new services, how leaked credentials are revoked, and whether the platform can separate administrator credentials from application credentials. Request a documented rotation procedure and a test record showing that a credential was rotated without downtime.

Which platform fits which requirement profile

This profile covers workloads where events are written at high volume, kept for a long time and replayed by several independent consumers. Apache Kafka is a mature fit for this pattern: it is an Apache Software Foundation project under Apache-2.0 with no paid edition from the project itself, and its supported releases are listed on the downloads page. Apache Pulsar separates brokers from storage, so capacity grows by adding BookKeeper bookies independently of brokers, which matters when retention grows faster than message rates. NATS JetStream offers replay from the beginning, the latest message, a sequence number or a point in time, but its clustering guidance (an odd number of servers, R3 as the production floor, at most five copies per stream) is worth testing against your retention volume. RabbitMQ is not covered by the facts supplied for this checklist, so confirm its fit for long retention and replay with the project and your own load tests.

  • Kafka operating baseline: Brokers and Kafka Connect require Java 17 from Kafka 4.0 onward, and ZooKeeper-based clusters must migrate to KRaft before upgrading to 4.x.
  • Pulsar storage model: Brokers are stateless and BookKeeper bookies hold persistent storage, which separates compute and capacity planning.
  • Pulsar metadata store: Oxia is recommended for new clusters, with ZooKeeper and RocksDB also available.
  • NATS replay options: JetStream streams can store messages in memory or on disk, and consumers can replay from several starting points.
  • Retention sizing: Ask every candidate for measured throughput and disk growth at your planned retention, not peak marketing figures.

Check how each platform's storage, replication and upgrade path behaves at your expected retention before you shortlist it.

Integration requirements that shape the design

Before choosing a broker, agree on who produces and consumes events, which languages and bridges those connections need, and where data changes originate. These answers decide whether a platform fits without custom glue, and they set the connector and schema work that recurs after launch.

Producers and consumers that must connect

List every system that publishes or subscribes, including legacy applications, batch jobs, vendor products and partner endpoints. For each, record the protocol it can speak, whether it can hold a persistent connection and how many clients will connect at peak. A broker can accept Kafka API, AMQP or MQTT traffic, but a source that only speaks a vendor protocol needs an adapter. Test one representative producer and one consumer per protocol before committing to a platform.

Client languages and official tiers

Confirm which languages your teams and applications use, then check the client support level for each. NATS publishes Tier 1 clients for Go, JavaScript/TypeScript, Python, Java, Rust, C#/.NET and C, while Zig, Swift, Ruby and Elixir are Tier 2 and may lag on new server features. Kafka clients are maintained across many languages through the community, so check the version each client library targets. Build a small test harness in each language you must support, including authentication and retry behavior.

Bridges to other systems

Identify the systems that need a native bridge rather than custom code, such as JMS queues, Spark or Flink jobs, and Kafka topics. The NATS documentation lists bridges to Kafka, JMS, Spark and Flink, along with a Prometheus exporter and Kubernetes tooling. Kafka relies on Kafka Connect and third-party connectors for most of these links. Ask whether each bridge is maintained by the project, by the vendor or by your own team, because that answer sets who patches it.

Change data capture sources

Name each operational database that must publish row-level changes, along with its engine, version and whether the database team allows log-based capture. Change data capture usually runs through Kafka Connect connectors, and each source has its own permissions, snapshot behavior and schema change handling. Record which tables carry personal or regulated data, because those topics inherit the same access rules. Test a snapshot and a schema change on a non-production copy before agreeing the source list.

Connector plugins and their supply chain

Decide which connector plugins you need, who approves them and how they reach each cluster. Connectors are separate artifacts with their own licenses, maintainers and release cadence, so each one adds a version to track. In an isolated network, plugins must be imported and verified before they can run, which adds a review step to every upgrade. Confirm the licence of each connector, its last release date and whether a patch can be applied without a full cluster restart.

Schema management and compatibility

Decide where event schemas live, who may change them and which compatibility rule applies before a change reaches consumers. A schema registry or equivalent gives producers and consumers a shared contract, but it must be deployed, secured and backed up like the broker itself. Ask whether teams need forward, backward or full compatibility checks, and whether breaking changes require a new topic. Test a deliberately incompatible change in staging to confirm the registry rejects it.

How to set operating requirements and team skills

This sequence turns availability, upgrade and staffing questions into a written operating model before any platform is selected, so the streaming choice rests on what the team can actually run.

  1. Set availability and recovery targets with the business owner

    The business owner of each event-driven service states how long the service can be unavailable and how much recent data it can afford to lose. The platform team translates those answers into targets for each stream, separating critical flows such as payments or orders from analytics feeds that tolerate delay. Done means each stream has a named owner and written targets, with the replication design (single site, multi-site or none) traced back to them. Confirm these targets before any sizing work, because they determine how many brokers, replicas and sites the platform needs.

  2. Confirm the number of environments and clusters

    Platform engineering lists the environments required (development, test, staging, production) and decides whether production needs one cluster or several, for example to separate regulated data or to isolate failure domains. Each cluster adds broker capacity, upgrade work, monitoring and certificate management, so the count should be justified by a requirement rather than by habit. Done means a signed list of clusters with their purpose, owner and the data classes each one may carry.

  3. Map Java and runtime versions the platform needs

    The platform engineer records the runtime each candidate needs and checks it against the organization's approved JDK and operating system baseline. For Apache Kafka, the upgrade notes state that since Kafka 4.0 brokers, Kafka Connect and tools require Java 17 and clients and Kafka Streams applications require at least Java 11. Teams running any ZooKeeper-based Kafka cluster must migrate to KRaft before upgrading to 4.x, and clusters older than 3.3.x are advised to move to 3.9.x first. Done means a version matrix covering brokers, Connect, tools, client libraries and the current JDK in use, with any gaps logged as work items.

  4. Define the upgrade cadence against supported release windows

    The platform owner sets how often the cluster will be upgraded and which releases it may run on. The Kafka downloads page lists 4.3.1, 4.2.2 and 4.1.2 as supported releases, and the time-based release plan says rolling upgrades are supported from each release in the past year to the latest version. Pulsar and NATS publish their own support windows, which the team should confirm on the project pages before choosing. Done means a written cadence, a maximum allowed lag behind the newest supported release, and a rehearsal of the rolling upgrade in a non-production cluster.

  5. Assign on-call and monitoring ownership

    The operations lead names the team that receives alerts for broker health, under-replicated partitions, consumer lag, disk growth and certificate expiry, and who carries the pager outside business hours. Each alert is mapped to a runbook and an escalation path, including who can approve a failover. Done means a rota, a documented alert inventory and a tested escalation path, confirmed by a short drill that shows the right person is paged for a simulated broker failure.

  6. Assess team skills against the chosen platform

    The engineering manager compares the skills the team already has (Linux, JVM tuning, TLS and certificate management, identity integration, Kubernetes or VM operations, client library ownership) with the skills the chosen platform demands. Gaps are recorded per person and per role, not per team, so training and hiring decisions are specific. Done means a skills matrix signed by the platform owner, with each gap marked as trained, hired or covered by a partner.

  7. Decide what the internal team runs and what a partner runs

    Leadership separates the operating tasks into three groups: tasks the internal team will own every day, tasks a partner will perform under a written scope (for example implementation, hardening, upgrades or continuous support), and tasks that remain with the business owner, such as approving data access. Partner scope should be written so that each handover item has an acceptance check. Done means a responsibility matrix that names an owner for every task in the runbook, which becomes the basis for the requirements to send to any implementation partner.

Operational requirements and how to verify them

This table pairs each operational requirement with the evidence to request from a platform team or partner and a test to run before go-live. Use it to turn general promises about upkeep into checks you can observe in a staging cluster. The main takeaway is that lifecycle, backup and handover claims are only credible once a restore or rolling upgrade has been run and documented.

RequirementEvidence to requestTest to run
Upgrade and support lifecycleNamed release line, end-of-support dates and the upgrade path from your current version. For Kafka, confirm the supported release list on the downloads page and that ZooKeeper-based clusters have moved to KRaftRolling upgrade of a staging cluster from your current version to the target, with client compatibility checked before and after
Pulsar support windowsConfirmation of the LTS line in use and its active and security support end dates, plus the feature release cadence the team will followDry-run of a broker and bookie upgrade against a copy of production topics, recording any configuration changes required
NATS release cadenceServer version pinned in the design, the process for taking patch releases, and the JetStream cluster layout (odd node count, R3 minimum)Rolling restart of one JetStream node at a time while a producer and consumer keep running, measuring message loss and redelivery
Java and runtime maintenanceRequired JDK version per component (brokers, Connect, clients, Streams apps), owner of JDK patching and the change record for each updateUpgrade the runtime in staging and confirm brokers, connectors and client applications start and pass smoke tests
Backup and restore of topics or streamsWritten backup method (broker-level copy, mirroring, or topic export), retention settings used for recovery, and the recovery point the design targetsRestore a topic or JetStream stream into an empty cluster, then compare message counts, offsets and consumer positions with the source
Monitoring and alertingMetrics exported for brokers, consumer lag, disk use, under-replicated partitions, leader elections and stream health, with named alert ownersInduce a broker stop and a consumer lag spike in staging, confirm alerts fire to the on-call route and close with a recorded response
Capacity planningSizing model linking throughput, message size, retention, replication factor and partition count to disk and network needs, with headroom assumptionsLoad test at expected peak plus growth margin, confirming disk growth rate matches the model over a sustained run
Documentation and handoverRunbooks for failover, upgrade, certificate rotation and topic onboarding; architecture diagrams; named owners for each systemHand the runbooks to the internal team, have them execute one restart and one topic change unaided, and log gaps

Which compliance requirements belong in the checklist

A streaming platform rarely carries a compliance label of its own. Assessors and auditors test the controls around it, so the checklist should capture the evidence those frameworks will sample: access control lists, encryption settings, log retention, change records and recovery tests. For Kafka, that means writing down who may produce to and consume from each topic, which authentication mechanism each listener uses (SSL or one of the documented SASL mechanisms), and whether the cluster allows unauthenticated access. In KRaft clusters, ACLs live in the cluster metadata log, and the checklist should record how allow.everyone.if.no.acl.found is set, because resources without ACLs are otherwise restricted to super users. Agree on the owner of each of these settings before the platform is chosen, since the answer shapes the architecture.

Retention and change control need the same discipline. Decide which broker and audit logs must be kept, for how long, and where they are stored outside the cluster, and confirm that configuration changes to brokers, topics and ACLs are recorded with an approver. Recovery tests are evidence too: the checklist should name the restore exercise, its frequency and the record of its results. Where a stream feeds an AI system, the EU AI Act adds specific duties. Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Ask legal counsel whether any of your streams fall within that scope, and confirm the retention period with them rather than assuming it.

DeployOpen plans and implements these controls, configures the platform to match them and prepares the evidence an assessment will request. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Sector frameworks such as PCI DSS, DORA or HIPAA add their own requirements, which are covered on the sibling pages for those industries. Use this section to agree the list of frameworks in scope, the owner of each control and the evidence format before scoping begins, so that the implementation can be tested against what an assessor will actually ask for.

Questions buyers ask before choosing a streaming platform

How much effort and cost does a streaming requirements exercise take?

The exercise costs internal time first, and external time only if you buy outside help. The main drivers are the number of systems that will publish or consume events, how many distinct data classes are involved (for example, payments, personal data or operational telemetry), and how many compliance regimes apply. Each additional regime adds review cycles from security and compliance staff. Ask any partner for a fixed-scope written proposal that lists the systems in scope, the workshops, the deliverables and the decisions the document must support. Recurring costs begin later, when the chosen platform is run, so the requirements phase is mostly one-time effort. DeployOpen does not publish a price list; a quote follows from the written scope.

How long do a requirements workshop and proof of concept take?

Duration depends on scope, not on a standard figure. A workshop series is shorter when one business unit with a few well-documented systems is involved, and longer when several business lines, security reviewers and regulators must agree. A proof of concept is timed by what it must prove: throughput at expected peaks, failover behavior, upgrade procedure, or integration with a specific connector. Ask for a timeline tied to named milestones and a list of the environments and data used. Also confirm the upgrade path with the vendor for the version you plan to run. For example, Apache Kafka 4.0 supports only KRaft mode, so any ZooKeeper-based cluster needs migration planning before that step.

What does the internal team need to contribute?

Three roles are needed from your side, and they should be named before work starts:

  • A product owner who can decide which event flows matter, their owners and acceptable delays.
  • Platform engineers who know the network, identity provider, Kubernetes or virtualization estate, and backup tooling where the cluster will run.
  • A security reviewer who sets requirements for encryption, authentication, authorization and log retention.

Plan for the product owner to make decisions on ordering, retention and replay scope, because those choices drive most of the later design. Engineers should be available for environment access and review sessions. Without these commitments, workshops tend to stall on open questions that nobody owns.

Can our team run the requirements exercise without outside help?

Yes, many teams can, provided they have someone who knows event-driven design and the regulatory obligations that apply. The work includes listing producers and consumers, classifying the data in each flow, measuring expected message rates and sizes, and deciding on ordering, delivery and retention needs. Outside help is most useful for challenging assumptions, mapping requirements to the protocols and features of Apache Kafka, Apache Pulsar or NATS, and producing evidence that a compliance assessor can review. If you do the exercise yourself, write the output as a decision record with reasons, so the choice can be defended later.

Can one streaming platform meet all of our requirements?

It depends on how far the requirements diverge, and many organizations end up with more than one messaging system. Kafka has the broadest ecosystem of connectors and clients and supports SSL and several SASL mechanisms, including SCRAM-SHA-512 and OAUTHBEARER. Pulsar is designed for multi-tenancy, quotas and geo-replication, and separates brokers from BookKeeper storage. NATS is a small single binary with JetStream for persistence and key-value and object stores, and its accounts isolate messaging domains. Test each candidate against your protocol needs, such as MQTT at the edge or AMQP for existing applications, and confirm support for those protocols with the project before deciding. Ask a partner to show where a single platform falls short.

What should we do when requirements conflict, such as strict ordering with very high throughput?

Treat the conflict as a decision to record, not a problem to hide. Strict ordering is usually enforced per key or partition, so the question becomes which events need global order and which need only order per entity. Ask whether the business can accept per-key ordering, whether consumers can tolerate reprocessing, and what the peak load looks like. Options include partitioning by entity, splitting a stream by business domain, or relaxing ordering for analytics flows while keeping it for transactional ones. Each option changes the cost of brokers, storage and on-call effort, so model the trade-off before the proof of concept starts.

What should a partner deliver at the end of the requirements phase?

A good partner delivers a document your team can act on without them. Expect:

  • A requirements register listing each flow, its producers, consumers, data classes, ordering, delivery and retention needs.
  • Decision records for protocol, platform and tenancy choices, with the alternatives considered.
  • A sizing model with stated assumptions, and a list of what must be measured in a proof of concept.
  • Security requirements mapped to controls you will need to evidence, and a list of open questions with owners.

Ask for these in the written scope so acceptance criteria are clear. DeployOpen plans and documents engagements this way, but the exact deliverables are agreed in writing for each project.

How DeployOpen scopes and delivers streaming platform selection

DeployOpen turns the requirements in this checklist into a written scope before anyone chooses a broker. We then plan, implement and harden the chosen platform inside your own data centers or cloud accounts, and document it for handover.

How we scope

  • Workshops to record throughput, retention, ordering and delivery needs for each event flow
  • Written list of protocols, clients and integrations the platform must support, including Kafka API, AMQP or MQTT where relevant
  • Agreed security, tenancy, geo-replication and operating-skills requirements, with the scope, deliverables and timeline confirmed in writing before work starts

How we build

  • Proof-of-concept deployment of the shortlisted Kafka, Pulsar, NATS or RabbitMQ options against your own sample workloads
  • Configuration of TLS, authentication, authorization and tenant isolation according to the agreed requirements
  • Load, failover and upgrade-path tests run in your environment, with results recorded against the written acceptance criteria

How we hand over

  • Architecture and decision record explaining why the chosen platform and versions fit each agreed requirement
  • Runbooks for topic provisioning, backup, restoration, monitoring and version upgrades, written for your operations team
  • Knowledge transfer sessions with your platform and security engineers, followed by a documented handover of access and responsibilities

How we support

  • Optional retainer for patching, upgrades, monitoring follow-up and periodic failover testing after go-live
  • Scheduled review of requirements as volumes, retention or compliance obligations change over time
  • Ongoing testing and support scope agreed in writing, so your team knows what DeployOpen covers and what stays in-house

Related

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.
Book a callhello@deployopen.com