Implement a crypto order management system

You are building an in-memory crypto order management system. You must parse commands from standard input and print outputs for query commands.

Order model

Each order has:

• orderId (string, unique)
• symbol (string, e.g., BTC-USD)
• side (BUY or SELL)
• qty (positive integer)
• state ∈ {LIVE, PAUSED, CANCELLED}

New orders start in state LIVE.

Input

A sequence of newline-separated commands. Your program should ignore blank lines.

Commands

• CREATE <orderId> <symbol> <side> <qty>

  • Creates a new order. If orderId already exists, treat it as an error (see Errors).

• PAUSE <orderId>

  • If the order exists and is LIVE, change it to PAUSED.

• RESUME <orderId>

  • If the order exists and is PAUSED, change it back to LIVE.

• CANCEL <orderId>

  • If the order exists and is not already CANCELLED, change it to CANCELLED.

• GET <orderId>

  • Print the current state as: <orderId> <state>.

• COUNT <state>

  • Print how many orders are currently in that state as a single integer.

Errors

For invalid commands or invalid transitions (e.g., RESUME on a LIVE order, or referencing an unknown orderId), print:

• ERROR

(You may assume command tokens are space-separated.)

Output

Print one line per GET and COUNT command, and also one line (ERROR) for each command that errors.

Constraints

• Up to 200,000 commands.
• orderId length ≤ 64.

Notes

Design your data structures so that GET and COUNT are efficient, and state transitions do not require scanning all orders.

Implement a Crypto Order Management System

You are given a list of newline-style command strings for an in-memory crypto order management system. Process the commands in order and return the lines that would be printed.

Each order has:

• orderId: unique string
• symbol: string such as BTC-USD
• side: BUY or SELL
• qty: positive integer
• state: one of LIVE, PAUSED, CANCELLED

Rules:

• New orders start in state LIVE.
• Blank lines must be ignored.
• Successful CREATE, PAUSE, RESUME, and CANCEL commands produce no output.
• GET <orderId> outputs: "<orderId> <state>".
• COUNT <state> outputs the number of orders currently in that state.
• Any invalid command, malformed command, invalid side/state/qty, duplicate orderId, unknown orderId, or invalid state transition must output "ERROR".

Valid commands:

• CREATE <orderId> <symbol> <side> <qty>
• PAUSE <orderId> only valid when the order is LIVE
• RESUME <orderId> only valid when the order is PAUSED
• CANCEL <orderId> only valid when the order exists and is not already CANCELLED
• GET <orderId>
• COUNT <state>

Your goal is to design the processing so that GET and COUNT are efficient and state transitions do not scan all orders.

Examples

Example 1

Input: (["CREATE ord1 BTC-USD BUY 5", "CREATE ord2 ETH-USD SELL 3", "GET ord1", "COUNT LIVE", "PAUSE ord1", "GET ord1", "COUNT PAUSED", "CANCEL ord2", "COUNT CANCELLED", "RESUME ord1", "GET ord1"],)
Output: ["ord1 LIVE", "2", "ord1 PAUSED", "1", "1", "ord1 LIVE"]

Explanation: Two orders are created as LIVE. ord1 is paused and later resumed. ord2 is cancelled. GET and COUNT return the current states and totals.

Example 2

Input: (["CREATE a BTC-USD BUY 10", "CREATE a BTC-USD BUY 1", "RESUME a", "PAUSE missing", "PAUSE a", "PAUSE a", "CANCEL a", "CANCEL a", "GET a", "COUNT LIVE"],)
Output: ["ERROR", "ERROR", "ERROR", "ERROR", "ERROR", "a CANCELLED", "0"]

Explanation: This covers duplicate CREATE, invalid RESUME from LIVE, unknown orderId, invalid PAUSE on an already PAUSED order, and invalid CANCEL on an already CANCELLED order.

Hints

1. Use a hash map from orderId to its current state so GET and state transitions are constant time on average.
2. Maintain running counts for LIVE, PAUSED, and CANCELLED; update the counts whenever an order changes state.