Sounds like a classic windowing hiccup. Grab a profiler first – Java Flight Recorder or your cloud’s native traces work well for streamers. Turn on the “time spent in user code” metric and watch the window operator’s CPU span. If you see the “merge” or “purge” steps ballooning, you’re probably allocating too many objects per event. Next, check your window type. Sliding windows with a very small slide and large size will churn out a lot of partial aggregates. Switching to a tumbling window or using a fixed‑size ring buffer for incremental aggregation can cut that down. Make sure you’re not rebuilding the window from scratch on every event; incremental aggregations that update the state in place are far cheaper. Look at the state store access pattern too. If you’re hitting the disk for every key, you’ll get latency spikes. In RocksDB, keep the write buffer large enough and batch writes – that reduces I/O contention. Also, tune the checkpoint interval; too frequent checkpoints will add overhead, too infrequent will leave you vulnerable to long recovery times. Finally, profile the JIT. If you’re in a tight loop, force a hotspot compilation by running a warm‑up batch. After that, tweak the data structure: a Long2ObjectMap or a primitive‑based array can beat a generic HashMap for high‑frequency keys. So: start with a trace, isolate the window operator, switch to incremental aggregation, batch state writes, tune checkpoints, and let the JIT do its magic. Coffee in hand, we’ll shave milliseconds into microseconds.