How do I set parallelism and backpressure correctly in a Flink streaming job?

Backpressure gets treated like an alarm to silence. It's actually one of the more useful signals Flink gives you for free: it tells you, precisely, which operator in your pipeline is the bottleneck everything else is waiting on.

Reading backpressure correctly

Backpressure propagates backward through the job graph — if operator C is slow, operators A and B upstream of it will show high backpressure too, even though they're not the actual problem. The fix is to find the first operator (reading the graph in data-flow order) that shows high backpressure with nothing downstream of it also backpressured — that's your actual bottleneck, not whichever operator has the flashiest metric.

Parallelism should follow the bottleneck, not be uniform

Setting one global parallelism value for the whole job is the most common Flink misconfiguration — it either over-provisions cheap operators or under-provisions expensive ones. Per-operator parallelism, set higher specifically on the operator identified as the real bottleneck above, is almost always both cheaper and faster than raising global parallelism until the slowest operator keeps up.

Checkpoint duration is a second, independent signal

Checkpoint duration climbing over time — separate from backpressure — usually means state size is growing faster than your parallelism/resources can checkpoint it within your configured checkpoint interval. Left unaddressed, this eventually causes checkpoint timeouts, which in turn can trigger unnecessary job restarts. This is a leading indicator worth watching even when backpressure looks fine today.

Watermark configuration causes a specific, sneaky version of this

An out-of-date or overly lenient watermark strategy can make windows hold state far longer than intended, which looks like a parallelism/capacity problem but is actually a windowing-logic problem — increasing parallelism won't fix it, only correcting the watermark/allowed-lateness config will.