Query Order and Batch Lifetimes from Event Files

# Query Order and Batch Lifetimes from Event Files An event has a timestamp, an order ID, and a batch ID. Open events are written to one file and close events to another; an order that is still open has no close event. Existing lookup code can find a timestamp for one target ID. Redesign the lookup so the target may be either an order ID or a batch ID. For an order, return its start and end timestamps. For a batch, return the earliest start among its orders and the latest end, except that the batch end must be `0` if any order in the batch has no close event. ### Constraints & Assumptions - State how target kind is distinguished and how duplicate or malformed events are handled. - Files may be too large to load repeatedly for each request. - Timestamp zero is reserved for an incomplete end. ### Clarifying Questions to Ask - Are event files sorted, append-only, and uniquely keyed by order ID? - Can an order move between batches or have duplicate open/close records? - Is the workload one lookup or many repeated lookups? ```hint Define the batch invariant A batch end is known only when every member order has a close event, regardless of the latest closed order. ``` ### What a Strong Answer Covers - Correct order and batch semantics, including incomplete batches. - Streaming or indexed file access and explicit memory/I/O trade-offs. - Validation of duplicates, missing events, and inconsistent batch IDs. - Complexity for one scan and repeated-query designs. ### Follow-up Questions - How would the design support files being appended during queries? - What index would you build when batch lookups dominate?