Order Processing System - Architecture Review

This is a working order processing system built with Elixir/OTP. The codebase is clean, well-documented, and fully tested. However, it has architectural limitations that would prevent it from scaling in production.

System Overview

The system processes e-commerce orders through a five-stage pipeline:

1. Validation - Verifies order data completeness
2. Inventory Check - Confirms product availability
3. Payment Processing - Authorizes payment
4. Fulfillment - Prepares shipping information
5. Notification - Sends customer confirmation

Architecture

OrderProcessing (Public API)
    ↓
Pipeline GenServer (Single Process)
    ↓
Stages (Synchronous Function Calls)
    ├── Validator
    ├── InventoryChecker
    ├── PaymentProcessor
    ├── Fulfillment
    └── Notifier

Getting Started

Installation

mix deps.get

Running Tests

mix test

Interactive Usage

iex -S mix

# Process an order
OrderProcessing.process_order(%{
  id: "ORDER-001",
  customer_id: "CUST-123",
  items: [%{product_id: "PROD-1", quantity: 2, price: 29.99}],
  total: 59.98
})

# Check order status
OrderProcessing.get_order_status("ORDER-001")

# List all orders
OrderProcessing.list_orders()

# Filter orders
OrderProcessing.list_orders(status: :completed)
OrderProcessing.list_orders(min_total: 100.00)

Code Organization

lib/
├── order_processing.ex              # Public API
├── order_processing/
│   ├── application.ex               # OTP Application
│   ├── pipeline.ex                  # Main processing GenServer
│   ├── core/
│   │   └── order.ex                 # Order data structure
│   └── stages/
│       ├── validator.ex             # Validation logic
│       ├── inventory_checker.ex     # Inventory verification
│       ├── payment_processor.ex     # Payment handling
│       ├── fulfillment.ex           # Shipping preparation
│       └── notifier.ex              # Customer notifications

Testing

The system includes comprehensive test coverage:

• Unit tests for each stage
• Integration tests for the full pipeline
• Edge case and error handling tests

Run tests with:

mix test
mix test --trace  # Detailed output

Design Decisions

Current Architecture Characteristics

1. Single Pipeline GenServer

   • All orders processed through one GenServer
   • State maintained in-memory in the GenServer
   • Synchronous processing of orders

2. Direct Function Calls Between Stages

   • Stages are pure functions called sequentially
   • No message passing between stages
   • Tight coupling between pipeline and stages

3. In-Memory State

   • All order history stored in GenServer state
   • No persistence layer
   • State lost on restart

4. Synchronous Processing

   • Orders processed one at a time
   • Each stage blocks until complete
   • No concurrent order processing

5. Simple Error Handling

   • Errors fail the entire order
   • No retry mechanism
   • No partial failure recovery

Your Task

See interviewee.md for detailed instructions on reviewing this architecture and proposing improvements.

Questions?

Feel free to explore the code, run tests, and experiment with the system. The goal is to understand the current architecture and identify opportunities for improvement.