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.

Function
processOrderManager(operations: String[]) → String[]

Examples
Example 1
operations = ["CREATE o1 user_1 2026-03-20T09:00:00Z 5","CREATE o2 user-2 2026-03-20T10:00:00Z 3","CANCEL o1 2","ORDERS_BY_STATUS ACTIVE","ORDERS_BETWEEN 2026-03-20T00:00:00Z 2026-03-20T23:59:59Z","CANCEL o1 3","ORDERS_BY_STATUS CANCELLED","ORDERS_BY_STATUS ACTIVE"]
return = ["CREATED","CREATED","PARTIALLY_CANCELLED","o1,o2","o1,o2","CANCELLED","o1","o2"]
After canceling 2 units, o1 remains active with 3 units. The inclusive time query returns both orders. The second cancellation fully cancels o1, so it moves out of the active index and appears in the canceled-status query.
Example 2
operations = ["CREATE order-7 user_7 2026-03-21T12:00:00Z 10","CREATE order-7 user_8 2026-03-22T12:00:00Z 4","CANCEL order-7 11","CANCEL missing 1","CANCEL order-7 4","ORDERS_BY_STATUS ACTIVE"]
return = ["CREATED","DUPLICATE_ORDER","INVALID_CANCEL","ORDER_NOT_FOUND","PARTIALLY_CANCELLED","order-7"]
The duplicate create and over-cancellation are rejected without changing state. Canceling 4 units succeeds and leaves 6, so order-7 is still active.
Example 3
operations = ["CREATE a bad!user 2026-03-21T00:00:00Z 1","CREATE b user_b 2026-02-30T00:00:00Z 1","CREATE c user_c 2026-03-22T08:30:00Z 2","ORDERS_BETWEEN 2026-03-23T00:00:00Z 2026-03-22T00:00:00Z","ORDERS_BETWEEN 2026-03-22T00:00:00Z 2026-03-22T23:59:59Z","ORDERS_BY_STATUS CANCELLED"]
return = ["INVALID_USER_ID","INVALID_TIMESTAMP","CREATED","INVALID_RANGE","c",""]
The first user ID contains an unsupported character, and February 30 is not a real date. Only c is created. The reversed range is invalid; the valid range contains c, and no order is fully canceled.

Constraints
1 <= operations.length <= 100000.
Every operation has one of the documented forms.
order_id is non-empty and contains no spaces.
Every create or cancel quantity is a positive integer no greater than 10^12.
All quantities and cumulative canceled quantities fit in a signed 64-bit integer.
Every status query uses ACTIVE or CANCELLED.

The trick is bookkeeping. Keep a map from order ID to quantity remaining and original quantity, plus a list of order IDs in creation order. For status queries, maintain an active set and a cancelled set, and move an ID only when remaining hits zero. Iterate in creation order so output order is free. For time queries, keep a sorted structure keyed by (timestamp, creation index) and binary search the inclusive range. Since ISO timestamps in this exact format compare correctly as strings, you can sort on the raw string once validated. Pitfalls: checking user ID, then timestamp, then duplicate, in that exact order. Real calendar validation, including leap years and February 30. Rejected operations must change nothing. Fully cancelled orders stay in the time index. Empty string versus INVALID_RANGE is another easy slip. If the date logic eats your time, StealthCoder is the hedge during the live OA.

Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.