Utilizing progress identifiers to rewrite an event query

1. A method, comprising:

receiving events from one or more primary systems associated with one or more tenants; storing the received events in a message queue; ingesting at least a portion of the events in the message queue for organization and storage in a data store; tracking progress identifiers associated with ingesting of the events in the message queue; flushing and storing at least the portion of the events from the message queue into a shard of the data store corresponding to a tenant among the one or more tenants; receiving, from an external system, an event query associated with the tenant; rewriting the event query associated with the tenant into a first component query for the shard of the data store corresponding to the tenant and a second component query for the message queue based at least in part on a data store progress identifier, wherein the data store progress identifier indicates a most recent event that is stored in the shard corresponding to the tenant, wherein the shard of the data store corresponding to the tenant enables the events stored in the shard associated with the tenant to be identified and retrieved in less time than events associated with the tenant within the message queue, wherein the data store progress identifier is a boundary for the first component query and the second component query; and combining a result of the first component query and a result of the second component query to determine a result of the event query.

2. The method of claim 1 , further comprising:

performing the first component query and the second component query; and

providing the result of the event query to the external system.

3. The method of claim 1 , further comprising providing a notification of anomalous behavior to the external system.

4. The method of claim 1 , wherein each of the events received from the one or more primary systems associated with the one or more tenants has a corresponding progress identifier.

5. The method of claim 1 , wherein each of the one or more tenants is associated with a corresponding shard in the data store.

6. The method of claim 1 , wherein ingesting at least the portion of the events in the message queue includes copying one or more events associated with the tenant among the one or more tenants from the message queue to a buffer corresponding to the tenant.

7. The method of claim 6 , wherein ingesting at least the portion of the events in the message queue includes flushing one or more events from the buffer into shards corresponding to each of the respective one or more tenants.

8. The method of claim 7 , wherein the one or more events for the tenant are flushed after a threshold number of events have accumulated in the buffer corresponding to the tenant.

9. The method of claim 7 , wherein the one or more events for the tenant are flushed after a particular period of time has passed.

10. The method of claim 1 , wherein the event query associated with the tenant at least includes a start time, an end time, and a tenant.

11. The method of claim 10 , wherein a lower bound for the first component query is set to the start time.

12. The method of claim 10 , wherein an upper bound for the second component query is set to the end time.

13. The method of claim 10 , wherein an upper bound for the first component query and a lower bound for the second component query are set to the data store progress identifier for the most recent event that is stored for the tenant in the data store.

14. The method of claim 10 , wherein the event query associated with the tenant further includes an event attribute.

15. The method of claim 14 , wherein the event attribute is associated with an event attribute progress identifier that indicates an oldest event having the event attribute that is in a corresponding message buffer for the one or more tenants.

16. The method of claim 15 , further comprising determining whether an event attribute progress identifier precedes the data store progress identifier for the most recent event that is stored for the tenant within the shard of the data store corresponding to the tenant.

17. The method of claim 16 , in response to determining that the event attribute progress identifier does not precede the data store progress identifier for the most recent event that is stored for the tenant in the data store, setting an upper bound for the first component query as the data store progress identifier for the most recent event that is stored within the shard of the data store corresponding to the tenant and setting a lower bound for the second component query as the event attribute progress identifier.

18. A computer program product embodied in a non-transitory computer readable medium and comprising computer instructions for:

receiving events from one or more primary systems associated with one or more tenants; storing the received events in a message queue; ingesting at least a portion of the events in the message queue for organization and storage in a data store; tracking progress identifiers associated with ingesting of the events in the message queue; flushing and storing at least the portion of the events from the message queue into a shard of the data store corresponding to a tenant among the one or more tenants; receiving, from an external system, an event query associated with the tenant; rewriting the event query associated with the tenant into a first component query for the shard of the data store corresponding to the tenant and a second component query for the message queue based at least in part on a data store progress identifier, wherein the data store progress identifier indicates a most recent event that is stored in the shard corresponding to the tenant, wherein the shard of the data store corresponding to the tenant enables the events stored in the shard associated with the tenant to be identified and retrieved in less time than events associated with the tenant within the message queue, wherein the data store progress identifier is a boundary for the first component query and the second component query; and combining a result of the first component query and a result of the second component query to determine a result of the event query.

19. A system, comprising: a memory; and a processor coupled to the memory, wherein the processor: receives events from one or more primary systems associated with one or more tenants; stores the received events in a message queue; ingests at least a portion of the events in the message queue for organization and storage in a data store; tracks progress identifiers associated with ingesting of the events in the message queue; flushes and stores at least the portion of the events from the message queue into a shard of the data store corresponding to a tenant among the one or more tenants ;receives, from an external system, an event query associated with the tenant; rewrites the event query associated with the tenant into a first component query for the shard of the data store corresponding to the tenant and a second component query for the message queue based at least in part on a data store progress identifier, wherein the data store progress identifier indicates a most recent event that is stored in the shard corresponding to the tenant, wherein the shard of the data store corresponding to the tenant enables the events stored in the shard associated with the tenant to be identified and retrieved in less time than events associated with the tenant within the message queue, wherein the data store progress identifier is a boundary for the first component query and the second component query; and combines a result of the first component query and a result of the second component query to determine a result of the event query.