Stop Scanning the Whole Topic: Server-Side Filtered Reads for Agent Context

It sounds like the simplest request in the world: 'give me every event for order #8675309 in the last 24 hours.' On a database that's one indexed query. On your event log? You subscribe to the entire topic, stream millions of messages you don't want across the network, and throw 99.9% of them away client-side just to find the handful you needed. Now multiply that by every entity, and every agent doing it at once — you've built a gloriously expensive way to filter in exactly the wrong place.

This talk is about moving that work where it belongs: the broker. You express the predicate — an ID plus a time window — at subscription time, and you get back only the messages that match. We'll build it end to end: how the broker evaluates predicates without decompressing payloads, how a time-bounded read maps onto the log's segments and retention (a wide enough window can reach all the way into cold object storage), and exactly what you save versus client-side scanning in bandwidth, connections, and latency. We'll also stay honest about where this is not a database: you're reading an ordered log, not hitting a secondary index, and that shapes ordering, backpressure, and the failure modes you'll meet at scale — plus when to filter at the broker versus in a function versus the consumer.

Why does this matter right now? Because 'give me everything about entity X in this window' is the workhorse query behind assembling agent context, reconstructing a user session, debugging from point-in-time history, and pulling audit trails for compliance. Make it cheap and server-side, and a whole class of problems you're fighting today gets easier


By attending this session, your contact information may be shared with the sponsor for relevant follow up for this event only.