Requirements

Imagine you're building the core engine for a stock trading system. Forget the fancy UI and real-time market feeds for now. We're focused on the order management and execution aspects – the heart of any trading platform. This system needs to handle different order types (market, limit), manage orders efficiently, and execute them against a simplified in-memory order book. This problem requires a solid understanding of object-oriented principles and design patterns. We're not simulating a full exchange; instead, we're building a robust, extensible, and thread-safe core for handling order processing. It simulates matching buy and sell orders and recording trades. This is not about high-frequency trading or handling massive datasets. It's about crafting a clean, maintainable, and scalable design that can be easily extended to support more sophisticated order types, trading strategies, and risk management features in the future. Error handling, thread safety, and comprehensive testing are paramount. # Requirements ## Functional Requirements * **Order Placement:** * Accept buy and sell orders for a specific stock symbol. * Support at least two order types: Market Order and Limit Order. * Market Order: Executed immediately at the best available price. * Limit Order: Executed only at a specified price or better. * Each order should have the following attributes: * `orderId`: Unique identifier for the order. * `symbol`: Stock symbol (e.g., "AAPL", "GOOG"). * `type`: Order type (Market or Limit). * `side`: Buy or Sell. * `quantity`: Number of shares to trade. * `price`: (For Limit Orders) The limit price. * `timestamp`: Timestamp of order placement. * `status`: Current status of the order (e.g., NEW, PARTIALLY_FILLED, FILLED, CANCELLED, REJECTED). * **Order Cancellation:** * Allow users to cancel open orders. * Cancellation requests should update the order status appropriately. * **Order Execution (Matching Engine):** * Match buy and sell orders based on price and time priority. * For Limit Orders, match only if the order's limit price is met or exceeded. * When a match occurs, create a `Trade` record with the following attributes: * `tradeId`: Unique identifier for the trade. * `buyerOrderId`: Order ID of the buying order. * `sellerOrderId`: Order ID of the selling order. * `symbol`: Stock symbol. * `price`: Execution price. * `quantity`: Number of shares traded. * `timestamp`: Timestamp of the trade. * Update the status of the orders involved in the trade (PARTIALLY_FILLED or FILLED). * **Order Book:** * Maintain an order book for each stock symbol. * The order book should store buy and sell orders separately, sorted by price (and time for orders with the same price). * **Trade History:** * Maintain a history of all trades executed by the system. * **Concurrency:** Multiple clients should be able to place orders concurrently. ## Non-Functional Requirements * **Thread Safety:** The system must be thread-safe to handle concurrent order placements and cancellations. Use appropriate synchronization mechanisms to prevent race conditions and data corruption. * **Extensibility:** The system should be designed to easily support new order types (e.g., Stop Loss, Market-on-Close), new matching algorithms, and other features without requiring major code changes. Design Patterns like Strategy and Factory are key. * **Modularity:** The system should be divided into well-defined modules with clear interfaces to promote maintainability and testability. Consider appropriate abstraction levels. * **Testability:** The code should be written in a way that makes it easy to write unit tests and integration tests. * **Performance:** Although not a high-frequency trading system, the matching engine should be reasonably efficient. Choose appropriate data structures and algorithms for order book management. Avoid unnecessary locking that could degrade performance under concurrency. Use concurrent data structures where applicable. * **Error Handling:** The system should handle errors gracefully, such as invalid order parameters, insufficient funds, and market closures. Provide informative error messages. * **Code Quality:** The code should be well-documented, easy to read, and adhere to SOLID principles. ## Core Entities * **Order:** Represents a buy or sell order placed by a trader. It encapsulates all the information related to an order, including its ID, symbol, type, side, quantity, price (if applicable), timestamp, and status. * **OrderBook:** Represents the collection of active buy and sell orders for a specific stock symbol. It provides methods for adding, removing, and matching orders. It likely contains two priority queues (or similar data structures) – one for buy orders and one for sell orders. * **MatchingEngine:** The core component responsible for matching buy and sell orders and executing trades. It interacts with the OrderBook to find matching orders and creates Trade records when a match is found. This is where your matching algorithm will reside. * **Trade:** Represents a successful execution of a buy and sell order. It encapsulates information about the trade, such as the trade ID, buyer order ID, seller order ID, symbol, price, quantity, and timestamp. * **OrderService:** An interface (or abstract class) that defines the core operations related to order management, such as placing, canceling, and querying orders. * **TradeHistory:** A repository for storing and retrieving trade records. This can be a simple in-memory list or a more sophisticated database connection. * **OrderStatus:** An enum representing the different states an order can be in (NEW, PARTIALLY_FILLED, FILLED, CANCELLED, REJECTED). * **OrderType:** An enum representing the different types of orders supported (MARKET, LIMIT). * **OrderSide:** An enum representing the side of the order (BUY, SELL).

Design a stock trading system

Requirements

Interview Simulation

Functional Requirements

💡 Interview Tip

Non-Functional Requirements

Core Entity Identification

Premium Content