Order Manager with Partial Cancellations and Indexed Queries

Implement a lightweight order manager that creates orders, supports partial and full cancellation, and answers indexed status and creation-time queries.

Implement processOrderManager. Process the operations in order and return one result string for every operation.

Operation format

• CREATE order_id user_id created_at quantity: create a new order with a unique order ID, a valid user ID, a strict UTC creation timestamp, and a positive quantity. Validate the user ID first, then the timestamp, and then check for a duplicate order ID. Return CREATED, INVALID_USER_ID, INVALID_TIMESTAMP, or DUPLICATE_ORDER. A rejected create has no effect.
• CANCEL order_id quantity: cancel a positive quantity from an existing order. The canceled total may equal but never exceed the original quantity. Return PARTIALLY_CANCELLED while some quantity remains, CANCELLED when the remaining quantity becomes zero, ORDER_NOT_FOUND for an unknown ID, or INVALID_CANCEL when the quantity exceeds the remaining amount. A rejected cancellation has no effect.
• ORDERS_BY_STATUS status: status is ACTIVE or CANCELLED. Return matching order IDs as one comma-separated string in original creation order, or the empty string when none match. An order is active while its remaining quantity is positive. A fully canceled order is removed from the active set but retained in cancellation and history indexes.
• ORDERS_BETWEEN start_timestamp end_timestamp: return every created order whose creation timestamp lies in the inclusive range. Order the result by creation timestamp and then by original creation order for equal timestamps. Include fully canceled orders. Return the empty string when none match, or INVALID_RANGE when either timestamp is invalid or the start is after the end.

Validation rules

A valid user_id contains between 1 and 32 ASCII letters, digits, underscores, or hyphens. A timestamp must be a real UTC instant in exact YYYY-MM-DDTHH:mm:ssZ form using ASCII digits.

Interview follow-ups

The interview report also asked how to optimize status queries and persist runtime data. This callable exercise judges the in-memory behavior above. Maintain status and timestamp indexes rather than scanning every stored order for each query; database persistence remains a discussion follow-up.