Tee channel

Canonical guidance

• treat a tee as a coordination boundary, not a free broadcast primitive
• decide whether slow outputs should block, buffer, or cancel
• keep output ownership singular

Use when

• duplicating one stream into two processing branches
• diagnostics side streams
• paired consumers that both matter

Avoid

• assuming both outputs will always keep up
• multiple goroutines closing the outputs
• using a tee where one consumer can simply observe after the fact

Preferred pattern

• one goroutine reads each input value once and handles delivery policy to both outputs

Anti-pattern

• sending to the two outputs from unrelated goroutines with no common shutdown logic

Explanation: This is tempting because it looks parallel, but it usually scatters ownership and error handling.

Why

• duplicated streams still need one lifecycle owner