Order Management System

Ashutosh Kumar Singh

·

Follow

3 min read

·

Nov 7, 2024

--

1

Listen

Share

1. Class Diagram Design

Core Classes

• User
• Attributes: userId (String, unique), name (String), email (String), address (Address type).
• Methods: createAccount(), updateAccount(), deleteAccount(), viewProfile().
• Order
• Attributes: orderId (String, unique), userId (reference to User), orderStatus (enum: PLACED, SHIPPED, DELIVERED, CANCELLED), orderDate (Date), totalAmount (Double), orderItems (List of OrderItem).
• Methods: placeOrder(), updateOrderStatus(), cancelOrder(), calculateTotal().
• OrderItem
• Attributes: productId (reference to Product), quantity (Integer), price (Double).
• Methods: calculateSubtotal().
• Cart
• Attributes: cartId (String, unique), userId (reference to User), cartItems (List of CartItem).
• Methods: addItem(), removeItem(), viewCart(), emptyCart().
• CartItem
• Attributes: productId (reference to Product), quantity (Integer), price (Double).
• Methods: updateQuantity().
• Product
• Attributes: productId (String, unique), productName (String), description (String), price (Double), stock (Integer).
• Methods: checkAvailability(), updateStock().

Extended Classes and Utility Classes

• Payment
• Attributes: paymentId (String, unique), orderId (reference to Order), amount (Double), status (enum: PENDING, COMPLETED, FAILED), paymentMethod (enum: CREDIT_CARD, DEBIT_CARD, PAYPAL, etc.).
• Methods: processPayment(), refundPayment().
• NotificationService
• Attributes: notificationId (String, unique), userId (reference to User), message (String), status (enum: SENT, FAILED).
• Methods: sendNotification(), retryNotification().

2. API Design

Detailed API Endpoints

• Order Endpoints
• POST /orders
• Request Body: { "userId": "123", "cartId": "abc" }
• Response: 201 Created, { "orderId": "456", "status": "PLACED" }
• Logic: Validate stock and availability, create an order, move items from the cart to the order.
• GET /orders/{orderId}
• Response: 200 OK, { "orderId": "456", "userId": "123", "orderItems": [...], "totalAmount": 150.00 }
• Logic: Fetch and display order details, include order items and their status.
• PUT /orders/{orderId}
• Request Body: { "status": "CANCELLED" }
• Response: 200 OK, { "orderId": "456", "status": "CANCELLED" }
• Logic: Update order status, trigger notifications if needed.
• DELETE /orders/{orderId}
• Response: 204 No Content
• Logic: Validate the status and allow deletion only if the order is in a cancellable state.
• Cart Endpoints
• GET /cart/{userId}
• Response: 200 OK, { "cartId": "abc", "cartItems": [...] }
• Logic: Retrieve items in the user’s cart.
• POST /cart/{userId}/add
• Request Body: { "productId": "789", "quantity": 2 }
• Response: 201 Created, { "message": "Item added to cart" }
• Logic: Validate product stock, add item to the cart.
• Product Endpoints
• GET /products/{productId}
• Response: 200 OK, { "productId": "789", "productName": "Laptop", "price": 1000.00, "stock": 5 }

3. Design Patterns Applied

• Factory Pattern:
• To instantiate complex objects such as Order and CartItem with specific initializations, a factory class can be employed for controlled object creation.
• Observer Pattern:
• Used to notify users when order statuses change, such as from PLACED to SHIPPED or DELIVERED. NotificationService subscribes to Order events and sends notifications when triggered.
• Repository Pattern:
• Create separate classes for data access logic (e.g., OrderRepository, ProductRepository). This ensures a cleaner separation between business logic and database operations.

4. Handling Concurrency in the Database

Optimistic Locking

• Implementation:
• Add a version field to the Order table.
• Before updating an Order, check that the current version matches the version from when the record was read.
• If a mismatch is detected, reject the update and prompt the user to refresh and try again.

Pessimistic Locking

• Use Case: To handle cases where updates need to block other operations, such as stock updates during high traffic.
• Implementation:
• Use SELECT ... FOR UPDATE to lock rows until the transaction completes.

5. Deployment Strategy

Blue-Green Deployment

• Process:
• Set up two environments (Blue and Green). Run the current version on Blue.
• Deploy the new version to Green. Test the Green environment with internal or controlled traffic.
• When ready, switch production traffic to Green. If issues arise, switch back to Blue.

Canary Deployment

• Process:
• Deploy the new version to a small percentage of servers or users.
• Monitor for errors or performance issues. Gradually increase the percentage until the new version covers all traffic.

Rolling Updates

• Details:
• Deploy updates in batches (e.g., server by server).
• Ensures some servers continue to run the old version while others are updated.
• Reduces risk since not all servers are updated simultaneously.

Zero-Downtime Deployment

• Implementation:
• Use load balancers to manage traffic during deployment.
• Deploy using containerized microservices with tools like Kubernetes for orchestration.
• Ensure database migrations are backward-compatible to prevent downtime.

6. Ensuring System Reliability During Deployment

• Load Balancing:
• Use load balancers to route traffic to healthy instances only.
• Circuit Breakers:
• Implement circuit breakers to prevent cascading failures during partial deployments.
• Health Checks:
• Deploy instances with health checks to verify they are ready to serve traffic before being included in the load balancer’s pool.
• Feature Toggles:
• Roll out new features behind toggles, allowing activation post-deployment without needing a new deployment.