After a client reaches the entry address, what does the cluster hand back, and which addresses do later connections use?
answer
- two acts, not one
- the cluster describes itself
- each node announces its own address
- the work act uses announced addresses
- announced is configured, not inferred
basics
~20 sThe cluster answers the first connection with its own view of itself: the address each member announces, and which member currently serves which work. Every later connection targets those announced addresses, not the address the client originally dialled.
solid answer
~40 sThe connect step has two acts. In the first, the client opens a connection to the entry address and asks the cluster to describe itself. In the second, it connects to the members named in that answer and does the actual work there. What comes back is not derived from the connection the client arrived on: each member is configured with the address it announces about itself, so the client may be told a completely different address from the one it dialled. That is deliberate, because the same member has to be reachable from client populations sitting in different places. Clients refresh this view periodically and re-ask when it looks stale. Not every platform works this way — some answer every operation at one address, so the second act collapses to nothing.
go deeper
Hold on to the sequence: connect once to ask what exists, then connect again to do the work. The second connection is the one that carries records.
Be able to state that the announced address is configured on each node rather than derived from the client's connection, and say why an operator has to supply it.
Demonstrate that you know the two acts fail independently, and that a healthy first act proves almost nothing about whether work will succeed.
Treat which act your platform even has as an architectural fact worth knowing per platform, because it decides how much client-facing addressing your estate has to keep correct.
## The connect step is two acts, not one It is tempting to think of connecting to a cluster as a single event. It is two. 1. **The entry act.** The client opens a connection to the address it was configured with and asks one question: what does this cluster consist of? Any reachable member can answer. 2. **The work act.** The client opens connections to the members named in that answer and does its reading and writing there. On platforms where a stream is split into partitions and each partition's work is owned by a particular member, the second act is where essentially everything happens. The first act is a lookup. ## What comes back, and where it comes from The answer to the entry act is the cluster's own view of itself. Typically that is: - the **advertised address** of each member — the address that member announces for itself; - on split-stream platforms, which member currently serves which partition, so the client knows which connection to send a given record over; - enough structure for the client to notice, later, that its view has gone out of date. The crucial and frequently missed point is where the advertised address comes from. It is **configured on each node**, not inferred from the connection the client arrived on. A member does not look at the address you dialled and echo it back. It announces what it was told to announce. That sounds like a wart until you see why it exists: one member often has to be reachable by clients sitting in different places, under different names, and only the operator knows which name is right for which population. The node cannot deduce it. ## The two addresses, side by side | | the entry address | the advertised address | |---|---|---| | set by | the client's configuration | each node's configuration in the cluster | | used in | the entry act only | every connection of the work act | | relationship | may be one of the members, or something else entirely | need not resemble the entry address at all | | when it is wrong | the client never gets started | the client starts and then fails at work | ## Why the second act exists at all — and when it does not This is where platforms genuinely diverge, and a candidate who states one model as the class is making the classic error here. - Where a stream is split and each part is served by a specific member, the client **must** reach that member directly, so it must learn per-node addresses. Sending the write to the wrong member is not an option the client wants to take. - Where competing readers drain one shared work list, any member may be able to serve the client, and the second act can be much thinner — sometimes just staying on the connection already open. - Where a platform publishes a single address for everything, the second act does not exist. The client has one address and that is the entire reachability story. So "the cluster always hands back a node list" is a statement about one family of designs, not about brokers in general. ## How often the client repeats the entry act The client does not re-enter for every operation, and it does not learn the view once and keep it forever either. In practice: - it refreshes the cluster's view on an interval, so it notices ordinary change; - it re-asks when something it believed turns out to be wrong — a member it expected to serve some work no longer does; - it falls back to the entry address when it has no usable view left, such as at startup or after losing contact with everything it knew. That is why the entry address is kept in configuration rather than discarded after the first success: it is the re-entry path, even though it carries no work traffic. ## The practical consequence Because the two acts use two different sets of addresses, they fail independently. A client can complete the entry act perfectly — connection accepted, cluster described — and then be unable to do a single thing, because the addresses it was handed are not usable from where it sits. Understanding the second act as a separate connection to a separately configured address is what makes that failure obvious instead of mysterious.
- Why does each node announce a configured address rather than the cluster deducing it from the incoming connection?Because the same member frequently has to be reachable under more than one name, depending on where the client sits. The connection a client arrives on tells the cluster nothing reliable about which name is right for that client population, and other clients need a different one. Only the operator knows the mapping, so it is configuration.
- Does every platform in this class require the second act?No. It is required where work belongs to a particular member, so the client must reach that member. Where competing readers drain a shared work list, any member may serve the client and the second act can be thin. Some platforms publish one address for every operation and have no second act at all.
- How does a client notice that the view it holds has gone stale?Two ways together. It refreshes on an interval, so ordinary change is picked up without anything going wrong; and it re-asks on demand when an assumption fails — for example a member it believed serves some work says it does not. Neither alone is sufficient: the interval is too slow for sudden change, and on-demand alone leaves it blind between errors.
saying these in an interview costs you the question
- Thinks the client uses the same address for every operation
- Believes a node echoes back whatever address the client dialled
- Says the cluster view is fetched once and never refreshed
- Assumes every platform needs a second connection after the first
- Cannot say which address a later write actually goes to