Maybe you should think about maintaining an entity-centric index built from these events?
In your case the entity would be a "job". The example document looks like a state-change event and several of these could be summarised in a job entity. The advantage of this approach is:
- You can reduce the cost of joining fast-changing data (multiple events can be batched into a single update to the job entity)
- Custom attributes can be derived from multiple events e.g. "jobDuration" or "lastStatus".
- Your update scripts can see all job history and tag anomalies eg where state changes don't follow expected sequences