When a cross-cluster copier writes a record onto the target cluster, which properties of the record survive the hop?

## What the hop is, mechanically A **cross-cluster copier** reads records from a stream on the **source cluster** and appends them to a stream on the **target cluster**. Nothing exotic happens in between: it is a read on one side and an ordinary append on the other. So the right instinct for 'what survives?' is to ask what an ordinary append can carry, and what the receiving cluster decides for itself. ## What is carried, what is assigned, what varies | property of the record | across the hop | why | |---|---|---| | payload bytes | carried unchanged | this is the purpose of the copy; the copier does not interpret the payload | | routing key | carried unchanged | the key is part of the record and is needed for key-based placement on the target | | relative order | carried **conditionally** | only if one source part feeds one target part through a single ordered stream of writes | | per-record attributes | usually carried, by design choice | most copiers pass them through, some add their own marker, some drop unknown ones | | the record's timestamp | **varies** | some copiers preserve the source's timestamp, others let the target stamp arrival time | | the record's position number | **never carried** | the target assigns its own number as it appends | ## The condition that order depends on Order on the target holds when three things are true at once: 1. The records of a given part of the source stream all land in **one** part of the target stream. 2. **One** copier worker writes that part's records, so two workers cannot interleave. 3. Those writes are appended in the order they were read, and a failed append is retried before later records are written. Break any one of them and the ordering you had on the source is not the ordering on the target: - Running several workers over one source part to go faster interleaves their writes. - Reshaping the stream on the target - a different number of parts, or key-based placement that lands records differently - redistributes records across parts. - A retried append after a timeout can place a record later than its neighbours, or append it twice, which is why a copy is normally treated as at-least-once. The honest way to state this in an interview is operational: *the hop preserves the order it reads, for as long as the path from one source part to one target part stays single-threaded and unreshaped.* ## Why the timestamp question matters more than it looks If the target stamps arrival time, then every record copied after a backlog carries a timestamp clustered around the moment the backlog drained, not the moment the event happened. Two things then behave oddly on the target: age-based removal of old records starts its clock late, so history lives longer there than on the source; and anything that resumes a reader by time rather than by number lands in the wrong place. If instead the source timestamp is preserved, a large backlog can arrive already older than the target's retention rule allows, and records can be removed almost as fast as they arrive. Neither behaviour is wrong - but which one you have decides what the copy is good for, and it is a property of the copier you are running, not a universal. ## What does not ride the hop at all The copier copies **records**. Things that are not records travel, if at all, by a separate arrangement that somebody has to build: - the settings a stream was created with; - who is allowed to read or write it; - reader bookkeeping - where each reader group had got to; - the contracts payloads are validated against, and the identifiers those payloads carry. An engineer who says 'we mirror the cluster' and means 'the records are over there' is usually right about the records and wrong about everything else, and the gap only becomes visible the first time somebody tries to use the target for real. ## Where platforms differ On platforms that split a stream into parts and number records within each part, the whole question above is live, and 'one part to one part' is the phrase to reach for. On queue-shaped platforms where a consumer takes a message and acknowledges it away, the copier is a consumer that republishes: payload and key still survive, ordering guarantees are whatever the platform gives competing consumers in the first place, and there is no position number to preserve or lose because none exists. In both shapes, assume the copy is at-least-once unless you can show otherwise: a copier that is interrupted between appending and recording its own progress will re-append.