A Kafka bootstrap server is any broker address a client uses to make its first connection to a Kafka cluster. The client (a producer, consumer, or admin tool) issues a metadata request to the bootstrap broker, gets back the full list of brokers and partition leaders, then talks directly to the right broker for each request. The list passed via bootstrap.servers is only used to discover the cluster, not for ongoing traffic.
How a Kafka Bootstrap Server Works
When a Kafka client starts, it picks one address from bootstrap.servers, opens a TCP connection, and sends a Metadata request. Every Kafka broker can answer this request - it returns the cluster ID, the full broker list with hostnames and ports, and the leader replica for every partition the client cares about. From that point on the client talks directly to the partition leader for produce and fetch requests.
The client refreshes metadata in the background (default every metadata.max.age.ms = 300000 ms, i.e. 5 minutes) and on demand whenever it hits a NotLeaderForPartition or UnknownTopicOrPartition error. So even if the original bootstrap broker dies an hour later, the client keeps working - it already knows every broker in the cluster.
# Connecting kafka-console-consumer with three bootstrap addresses
kafka-console-consumer.sh \
--bootstrap-server kafka-1:9092,kafka-2:9092,kafka-3:9092 \
--topic orders \
--from-beginning
The default broker listener port is 9092 for PLAINTEXT and typically 9093 for SSL, but any port can be configured via listeners on the broker.
Configuring bootstrap.servers
bootstrap.servers is a comma-separated list of host:port entries. The list is consulted in order, with the client trying the next entry if a connection fails.
| Setting | Purpose | Typical value |
|---|---|---|
bootstrap.servers |
Initial broker addresses for cluster discovery | b1:9092,b2:9092,b3:9092 |
client.dns.lookup |
How DNS records are resolved | use_all_dns_ips (resolve all A records) or resolve_canonical_bootstrap_servers_only |
security.protocol |
Wire protocol used for the bootstrap connection | PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL |
request.timeout.ms |
How long to wait for a metadata reply | 30000 (30 s) |
reconnect.backoff.ms |
Initial backoff before retrying a failed bootstrap address | 50 |
reconnect.backoff.max.ms |
Cap on exponential reconnect backoff | 1000 |
The Kafka client documentation explicitly notes the bootstrap list does not need to contain every broker. Two or three entries are enough for redundancy because the first successful metadata response gives the client the complete cluster topology.
DNS round-robin and load balancers
A single DNS name resolving to all broker IPs (an A-record set) is a common pattern. With client.dns.lookup=use_all_dns_ips, the client will try every resolved IP before giving up on that bootstrap entry, which is the modern recommendation. Putting a TCP load balancer in front of brokers is supported but only useful for the bootstrap step - actual produce and fetch traffic goes directly to the broker that hosts the partition leader, bypassing the load balancer.
Common Mistakes with Bootstrap Servers
- Specifying only one address. If that broker is down during client startup, the client cannot connect even though the rest of the cluster is healthy. Always list at least two, preferably three.
- Using internal IPs that clients cannot route to. A frequent failure is brokers advertising a private IP via
advertised.listenersthat the client cannot reach. The client connects to the bootstrap address, gets back unreachable addresses, and then times out. - Pointing at decommissioned brokers. Old addresses in
bootstrap.serverscause slow startup as the client times out on each before reaching a live broker. - Assuming the bootstrap server handles all traffic. Some teams over-provision the "bootstrap" broker, then are surprised when it's barely loaded - bootstrap is one metadata request, not a proxy.
- Forgetting to align
security.protocolwith the listener. If brokers exposeSASL_SSLon port 9094 but the client usesPLAINTEXT, the handshake fails before any metadata is exchanged.
Monitoring Bootstrap Connectivity
For client-side health, watch:
connection-creation-rate/connection-close-rate(JMX, on every client) - spikes suggest the bootstrap broker is flapping.metadata-ageper client - rising age means the client cannot refresh and may be running on stale partition leaders.- DNS resolution time - if
bootstrap.serversuses DNS, a slow resolver delays every reconnect.
On the broker side, the RequestsPerSec metric for MetadataRequest reveals how much bootstrap and refresh traffic each broker is absorbing. If one broker takes the lion's share, your clients are not load-balancing across the bootstrap list (often because the first address resolves quickly and never fails).
Pulse monitors Kafka clusters end to end - brokers, controllers, topics, consumer groups - and catches the connectivity issues that surface as "bootstrap server unreachable" in client logs: bad advertised.listeners, partial network partitions, listener misconfigurations, and certificate expiry on SASL_SSL ports. Pulse also supports Elasticsearch, OpenSearch, and ClickHouse, with AI-driven root-cause analysis.
Frequently Asked Questions
Q: How many bootstrap servers should I specify in bootstrap.servers?
A: At least two, ideally three, for redundancy. The Kafka client only needs one successful metadata response to learn the full cluster, so listing every broker is unnecessary. Three covers the common failure case where one broker is down during client startup.
Q: Can any Kafka broker act as a bootstrap server?
A: Yes. Every broker in a Kafka cluster can answer a Metadata request. There is no special role or flag that designates a broker as a bootstrap server - the term simply means "the first broker a given client happens to contact".
Q: What happens if all bootstrap servers in the list are unreachable?
A: The client retries each address in sequence using exponential backoff (reconnect.backoff.ms up to reconnect.backoff.max.ms). If no metadata response arrives before request.timeout.ms, calls like producer.send() or consumer.poll() raise a TimeoutException. The client will keep retrying in the background.
Q: Does my client reconnect to the bootstrap server for every request?
A: No. After the first metadata response, the client opens direct connections to the broker that hosts the leader for each partition. The bootstrap list is only re-consulted if the client loses all live broker connections and has to rediscover the cluster.
Q: Can I use a load balancer instead of listing brokers in bootstrap.servers?
A: Yes for the bootstrap step. A TCP load balancer fronting all brokers gives clients a single, stable address for discovery. Note this only matters for the metadata request - actual produce/fetch traffic targets the partition leader's advertised.listeners address directly and bypasses the load balancer.
Q: What is the difference between bootstrap.servers and advertised.listeners?
A: bootstrap.servers is a client setting that tells the client how to reach any broker for the initial connection. advertised.listeners is a broker setting that tells the broker which hostname and port to advertise to clients in metadata responses. Clients use the second list, not the first, for ongoing traffic - which is why misconfigured advertised.listeners is a common cause of "client can connect but then hangs" symptoms.
Q: Do I need different bootstrap servers for producers and consumers?
A: No. Producers, consumers, Kafka Connect, Streams apps, and admin tools all use the same bootstrap.servers setting and the same cluster discovery flow. You can point them at the same list of brokers.
Related Reading
- Kafka Broker: the servers that the bootstrap connection lands on
- Kafka Listener: how brokers expose endpoints and
advertised.listeners - Kafka Topic: the unit of organization that clients ask metadata about
- Kafka Producer: clients that bootstrap to publish messages
- Kafka Consumer: clients that bootstrap to read messages
- Kafka Controller: the broker that coordinates cluster metadata
- Apache Kafka Glossary: all Kafka terms in one place
