Lesson 2: Bounded Channels and Backpressure

Time: 15-25 minutes

Source section: Bounded vs unbounded channels; BoundedChannelFullMode.

Speaking Goal

Explain bounded channels as a production safety mechanism and connect full-mode choices to business trade-offs.

Core Idea

An unbounded channel can accidentally turn memory into the buffer. A bounded channel forces an explicit decision when downstream cannot keep up: wait, drop, or degrade. That decision should match the value of the data.

Reusable English Sentence Structure: Hidden Cost, Explicit Policy, Business Meaning

Use these sentence frames for trade-off explanations:

The hidden cost of [simple option] is that [risk] moves somewhere less visible.
By making [capacity/policy/boundary] explicit, we force a decision about [overload/failure/trade-off].
For [critical data], I would choose [policy] because [business reason].
For [best-effort data], I might choose [different policy] because [business reason].
The key point is that [technical setting] is not only a code option; it represents [business meaning].

Example:

The hidden cost of an unbounded channel is that memory becomes the accidental buffer.
By making capacity explicit, we force a decision about what happens when consumers fall behind.
For inspection results, I would choose Wait because silently dropping defects is unacceptable.
For UI-only updates, I might choose DropOldest because freshness matters more than every intermediate state.

Model Answer

The main reason I prefer bounded channels in high-volume industrial streams is that they make overload behavior explicit. An unbounded channel feels convenient because writes keep succeeding, but if consumers are slower than producers, the backlog goes somewhere. Usually it goes into memory, and that is a dangerous accidental buffer.

With a bounded channel, capacity is part of the design. When the channel is full, we choose a policy. For inspection results that must be persisted, I would usually use Wait, because silently dropping defects would be unacceptable. For UI-only updates, I might use DropOldest, because the UI is best-effort and freshness matters more than showing every intermediate state.

That is the senior-level point: FullMode is not only a concurrency option. It is a business rule translated into runtime behavior.

Challenge Questions with Sample Answers

Question:

Why not always use Wait so we never drop data?

Sample answer:

Wait is right when the data is critical, but it can propagate pressure upstream. If the source cannot safely slow down, waiting may cause callbacks to pile up or block an SDK thread. For important inspection data, I still lean toward Wait, but I would measure the source behavior and add operational signals. For UI or telemetry summaries, dropping old values may be healthier.

Question:

How do you choose channel capacity?

Sample answer:

I would start from expected burst size, consumer throughput, memory budget, and acceptable latency. Capacity should absorb normal short bursts, not hide sustained overload. If the channel frequently reaches capacity, that is a signal to improve batching, scale consumers, reduce work, or change the degradation policy.

Question:

Is an unbounded channel always wrong?

Sample answer:

No. It can be fine for low-volume, naturally limited data where loss is unacceptable and memory risk is low. The mistake is using it by default for machine streams where input rate is not fully under our control.

Sample Conversation

Architect:

The UI channel drops old batches. Is that data loss?

You:

It is data loss only for the UI projection, not for the system of record. The persistence path keeps critical data with a stronger policy. The UI path is optimized for operator responsiveness and current state, so dropping stale visual batches is intentional.

Practice Drill

Explain this design choice in 90 seconds:

Raw and processed defect channels use Wait; the UI channel uses DropOldest.

Self-check:

• Did I distinguish critical data from display data?
• Did I mention memory growth?
• Did I explain overload behavior?
• Did I connect the technical choice to product risk?