Should I use a sliding window or a fixed window?

Per hour, per day, per calendar month: fixed. The giveaway is that somebody else named the period, usually for reporting or billing, and the parts have to add up to the whole. Adjacent fixed windows do not overlap and leave no gaps, so each event lands in exactly one of them and the monthly figure equals the sum of the daily ones. In the last five minutes, right now, this minute: sliding. The question is about a quantity that should be current, and no named period appears in it anywhere.

Alerting is the case that separates them. An error-rate alert run against an hourly fixed window reads whatever the last completed hour contained. Evaluated at an arbitrary moment, the oldest event behind that number is somewhere between zero and sixty minutes old, thirty on average, and the count drops back to zero at the top of each hour for a reason unconnected to the traffic. A five-minute window advancing every minute reports data no older than five minutes and never resets.

Under a sliding scheme an event is not a member of one window. With width $w$ and advance $h$, a new window opens every $h$ minutes and each stays open for $w$, so the event is still inside the ones that opened after it arrived until $w$ has elapsed. That is the count of windows it belongs to:

The window is identical in every row. Only the number of distinct keys changed, and the state moved by five orders of magnitude.

The common mistake is choosing fixed because it is what you drew first, then asking an alerting question of it. The quieter mistake costs more. Measure visits in fixed hourly windows and a visit running from 10:50 to 11:10 is recorded as two visits of ten minutes each. The total time is right, the count is one too high, and the mean visit length comes out low by an amount that depends on your window size rather than on your users. Nothing errors. The figure is plausible and wrong. Sliding windows fail in the opposite direction when the output has to reconcile: a one-hour window advancing every five minutes counts each event twelve times, so adding up an hour of output gives twelve times the traffic. That is fine on a dashboard and fatal on an invoice.

Session windows look cheap, one accumulator and one timer per active key, and they are until a key arrives just inside the gap every time. A key with an event every twenty-nine minutes under a thirty-minute gap never closes its session, so its accumulator grows for as long as the pipeline runs. Real systems cap session length, and a capped session has a boundary after all. The limit on the other two is cardinality rather than width: twelve regions under a fixed window hold $12 \times 200 = 2{,}400$ bytes, while four million user identifiers under the sliding window above hold 240 million accumulators. If the key space is unbounded, something has to expire idle keys, or the state grows forever. And none of this settles whether a window can be reported at all: a window ending at ten cannot be emitted at ten, because its events are still arriving, so whatever rule decides that no more are coming trades waiting against being wrong.