<a id="cloud-clients-faq"></a>

# Confluent Cloud Apache Kafka Client FAQ

You can connect to Confluent Cloud with Apache Kafka® clients in the language of your
choice. Confluent maintains the Java Client and the C/C++, Python, Go, .NET,
and JavaScript clients.

For an introduction, see [Build Streaming Applications on Confluent Cloud](overview.md#client-overview). To configure your first
client, see [Kafka Client Quick Start for Confluent Cloud](config-client.md#cloud-config-client).

## Client languages and versions

### Which clients does Confluent support?

Confluent supports the following clients:

* Java, which supports the producer, consumer, Kafka Streams, and Connect
  APIs.
* librdkafka-derived clients, which support the admin, producer, and
  consumer APIs:
  * [C/C++](https://github.com/confluentinc/librdkafka)
  * [Python](https://github.com/confluentinc/confluent-kafka-python)
  * [Go](https://github.com/confluentinc/confluent-kafka-go)
  * [.NET](https://github.com/confluentinc/confluent-kafka-dotnet)
  * [JavaScript](https://github.com/confluentinc/confluent-kafka-javascript)

Confluent doesn’t support community-developed clients,
including KafkaJS, Scala, Ruby, PHP, and Elixir.

For links to each client’s documentation and examples, see
[Client guides](overview.md#java-client-guides).

### Which client versions does Confluent support?

Confluent provides maintenance fixes for two years with Standard Support and
three years with Confluent Cloud Premier Support after the initial release of a minor
version. For details about which client versions Confluent supports,
including Java Development Kit (JDK) support, see [Client versions and support](overview.md#client-support-matrix).

### Are older clients being dropped?

Yes. [KIP-896: Remove old client protocol API versions in Kafka 4.0](https://cwiki.apache.org/confluence/spaces/KAFKA/pages/235838251/KIP-896+Remove+old+client+protocol+API+versions+in+Kafka+4.0)
deprecated older client protocols in Kafka 3.7 and removed these client
protocols from Kafka 4.0. Confluent extends compatibility for Confluent Cloud
clusters by one year. As of February 2026, Confluent Cloud rejects deprecated
client requests with errors.

For the minimum compatible versions of each client, see
[Client Deprecation in Confluent Cloud](deprecate-how-to.md#cloud-id-deprecated-clients).

### Which Java version should I use?

Unless you have an architectural reason to do otherwise, use the newest
long-term support (LTS) JDK that your Java client version supports.
The latest Java client supports JDK 25.

For details about the JDK supported for each client version, see [Java client support](overview.md#java-client-support).

## Connect Apache Kafka Clients to Confluent Cloud

### What is required to connect a client to Confluent Cloud?

At a minimum, a client must:

* Support TLS encryption and Simple Authentication and Security Layer (SASL)
  authentication, using `SASL_PLAIN` or `SASL_OAUTHBEARER`. `SASL_OAUTHBEARER`
  requires OAuth with OpenID Connect (OIDC) configured.
* Include the Server Name Indication (SNI) extension in the TLS handshake.
* Specify the cluster bootstrap endpoint and credentials.

For the complete list, see [Client Configuration Settings for Confluent Cloud](client-configs.md#client-producer-consumer-config-recs-cc).

### What ports does a client use?

Use port 9092 for Kafka protocol connections.

Use port 443 for REST connections, including:

* [Schema Registry REST API](../sr/sr-rest-apis.md#sr-rest-apis)
* [Kafka REST API](../kafka-rest/kafka-rest-cc.md#krest-overview)
* [Metrics API](../monitoring/metrics-api.md#metrics-api)

### Why does my client need to send the TLS SNI extension?

Confluent Cloud routes connections based on SNI. Confluent clients already send the
SNI extension. Any forward proxy in the network path must forward the SNI
extension unmodified.

For Kafka protocol connections on port 9092, the SNI extension must be set to
the DNS hostname of the bootstrap endpoint or of a broker. Broker endpoints are
discovered automatically during bootstrapping.

For REST connections on port 443, SNI must be set to the DNS hostname of the REST endpoint.

For more information, see [TLS SNI extension requirement](client-configs.md#client-tls-sni-requirement) and
[TLS connectivity testing](../networking/testing.md#test-tcp-sni-connectivity).

### Can I use a custom DNS name for my bootstrap endpoint?

No. You must use the original cluster bootstrap endpoint name. If you point a
custom DNS record at the cluster, TLS hostname validation fails.

### Do I need to install CA certificates?

For Java clients, certificate authority (CA) certificates are typically
already available in the JDK.

For librdkafka clients, including C/C++, .NET, JavaScript, Python, and Go,
install Let’s Encrypt TLS certificates locally. On Red Hat Enterprise Linux
(RHEL) and CentOS, the certificates are not present, so you must download them.

For librdkafka 2.11 and later, CA certificate discovery is typically automatic.
For librdkafka versions 2.10 and earlier, you might also need to set
`ssl.ca.location`.

For more information, see [Client Configuration Settings for Confluent Cloud](client-configs.md#client-producer-consumer-config-recs-cc).

### What are the recommended JVM settings for Java clients?

Set the following DNS-related properties so that clients pick up broker
address changes promptly:

Java Virtual Machine (JVM) security configuration
: ```none
  java.security.Security.setProperty("networkaddress.cache.ttl", "30");
  java.security.Security.setProperty("networkaddress.cache.negative.ttl", "0");
  ```

Kafka producer and consumer configuration
: ```none
  consumer.client.dns.lookup="use_all_dns_ips"
  producer.client.dns.lookup="use_all_dns_ips"
  ```

For more information, see [Client Configuration Settings for Confluent Cloud](client-configs.md#client-producer-consumer-config-recs-cc).

## Configuration and error handling

### Why do my clients log `NOT_LEADER_OR_FOLLOWER` warnings?

These warnings are expected during broker restarts, and clients recover
automatically. Confluent Cloud performs rolling restarts of brokers during routine
upgrades and maintenance. While a broker restarts, clients might briefly see
warnings such as `UNKNOWN_TOPIC_OR_PARTITION`, `LEADER_NOT_AVAILABLE`,
`NOT_COORDINATOR`, `NOT_ENOUGH_REPLICAS`, and
`NOT_LEADER_OR_FOLLOWER`.

By default, producers retry for two minutes, and consumer and admin clients
retry for one minute. Configure enough retries or retry time so these
warnings do not surface as errors in your application.

For more information, see [Cluster upgrades and error handling](client-configs.md#ccloud-rolls).

### Why do my clients log `Connection to node terminated during authentication`?

A client logs this `WARN` message when it connects to a broker that has just
restarted for maintenance. If this warning persists:

* Check for a firewall that blocks Kafka TLS traffic on port 9092.
* Confirm your credentials.

For more information, see [Cluster upgrades and error handling](client-configs.md#ccloud-rolls).

### Why do I get timeout exceptions under load?

Timeouts occur when clients exhaust the producer memory buffer while retrying
or run out of time waiting for buffer space. Review your batching, retry, and
buffer settings, and benchmark before tuning.

For detailed guidance, see [Optimize and Tune Confluent Cloud Clients](optimizing/overview.md#ccloud-optimizing).

### Should I increase the API version request timeout?

Yes. Before connecting a client application to Confluent Cloud, increase the timeout
for API version requests from the default of 10 seconds:

* For librdkafka clients, use `api.version.request.timeout.ms`.
* For Java clients, use `socket.connection.setup.timeout.ms`, which bounds
  connection setup, including the API version request. On repeated failures,
  this timeout doubles up to `socket.connection.setup.timeout.max.ms`,
  which defaults to 30 seconds.

## Consumers and share consumers

### Should I use a consumer group or a share group?

Use consumer groups when you need ordered processing.
Use share groups when you need parallelism beyond the partition count.

Consider these details when choosing a consumer group or share group:

| Attribute   | Consumers and consumer group                                                  | Share consumers and share group      |
|-------------|-------------------------------------------------------------------------------|--------------------------------------|
| Use cases   | Stream processing, analytics, or extract, transform, load (ETL)<br/>pipelines | Task-queue and operational workloads |
| Ordering    | Strict ordering within a partition                                            | No guaranteed ordering               |
| Scaling     | Scales 1:1 with partitions                                                    | Scales beyond the partition count    |

For a more in-depth comparison, see [Choosing consumer types](overview.md#choosing-consumer-types).

### How many consumers can I run in a consumer group?

Confluent Cloud doesn’t limit the number of consumers in a consumer group,
regardless of your rebalance protocol. For best performance, keep
your consumer group to 2,000 or fewer consumers.
If you add more consumers than partitions, the extra consumers are idle.
Partition count can constrain a consumer group because each partition is
assigned to only one consumer in the group.

Share groups remove the partition constraint by allowing many share consumers
per partition, but are limited to 200 share consumers per share
group on Enterprise clusters and 1,000 share consumers per share group
on Dedicated clusters.

For more information, see [Kafka Consumer for Confluent Cloud](consumer.md#kafka-consumer-cc),
[Share Consumers for Confluent Cloud](share-consumers.md#kafka-sharegroup-cc), and [Limits](share-consumers.md#share-group-limits).

### What happens to an event record that a share consumer keeps failing to process?

Each record carries a delivery count. Confluent Cloud archives the record when the delivery
attempts exceed the share delivery count limit. The limit defaults
to five. You can override the default with the Confluent CLI or Confluent REST API using
`share.delivery.count.limit`, with a minimum of two and a maximum of ten.

For the full set of limits, see [Limits](share-consumers.md#share-group-limits).

### Do I have to use a consumer group at all?

No. If you want explicit control over partition assignment and offset
management, call the consumer’s `assign()` method instead of `subscribe()`.
With `assign()`, the consumer reads from the partitions you name and does not
participate in group management, so `group.id` is optional.

If you commit offsets to Kafka, you must still set `group.id`, because it
identifies where those offsets are stored.

For more information, see [Choosing consumer types](overview.md#choosing-consumer-types).

## Test, tune, and monitor

### How do I test a client application without a cluster?

Use a mock interface and test the utilities for your client:

* JVM clients: `MockProducer` and `MockConsumer`
* Kafka Streams: `TopologyTestDriver` and `MockProcessorContext`
* librdkafka-based clients: `rdkafka_mock`
* End-to-end tests: Testcontainers, which runs dependencies in Docker

For best practices, see [Unit Testing](testing.md#ccloud-testing-unit) and
[Integration Testing](testing.md#ccloud-testing-integration).

### How should I benchmark my clients?

Establish a baseline with `kafka-producer-perf-test` and
`kafka-consumer-perf-test` before introducing application logic.

For JVM clients, measure the resulting throughput with the Java Management
Extensions (JMX) metrics that the Kafka producer and consumer expose. Run a
single client on a single server. Repeat the test, adding client
processes on each iteration, to find the number of processes per server
that achieves the highest throughput.

For non-JVM clients, use `rdkafka_performance`.
Then test your application starting from the default configuration and change
one variable at a time. Use realistic data, especially when testing
compression, because unrealistic mock data compresses better than production
data.

#### NOTE
These performance test tools do not support Schema Registry.

For the full method, see [Benchmarking](optimizing/overview.md#ccloud-benchmarking).

### What should I tune for?

Tune for one service goal at a time. These goals trade off against each
other:

* [Throughput](optimizing/throughput.md#optimizing-for-throughput)
* [Latency](optimizing/latency.md#optimizing-for-latency)
* [Durability](optimizing/durability.md#optimizing-for-durability)
* [Availability](optimizing/availability.md#optimizing-for-availability)

For more details, see [Optimize and Tune Confluent Cloud Clients](optimizing/overview.md#ccloud-optimizing).

### How do I monitor my clients?

Use the client’s [JMX metrics](jmx-monitoring.md#jmx-monitoring) or
[librdkafka statistics](jmx-monitoring.md#librdkafka-metrics)
for application-side visibility, and the
[Confluent Cloud Metrics](../monitoring/metrics-api.md#metrics-api) for cluster-side metrics.

For the metrics each client type exposes, see [Producer Metrics](producer-metrics.md#producer-metrics) and
[Consumer Metrics](consumer-metrics.md#consumer-metrics).

With [KIP-714: Client metrics and observability](https://cwiki.apache.org/confluence/display/KAFKA/KIP-714%3A+Client+Metrics+and+Observability),
Kafka clients push their client-side metrics to the broker.
In Confluent Cloud, client-side producer latency is the only KIP-714 metric
surfaced in the [Confluent Cloud Metrics](../monitoring/metrics-api.md#metrics-api).

Kafka Streams applications are an exception: they push a broader set of
metrics through the same mechanism. For the list, see
[Kafka Streams client metrics](monitoring.md#ccloud-monitoring-kafka-streams-client-metrics).

For broader client-side visibility, collect metrics with JMX or librdkafka
statistics.

## Related content

* [Build Streaming Applications on Confluent Cloud](overview.md#client-overview)
* [Kafka Client Quick Start for Confluent Cloud](config-client.md#cloud-config-client)
* [Architectural considerations for streaming applications on Confluent Cloud](architecture.md#ccloud-architecture)
* [Kafka Client Examples for Confluent Cloud](examples-index.md#client-examples)
* [Confluent Cloud Identity FAQ](../security/authenticate/identity-faq.md#cloud-identity-faq)
* [FAQ for Confluent Cloud](../faq.md#cloud-faq)