onyxwizard/orders-app repository overview

⁠🏗️ Order Management System — Stage 1: The Monolith

⁠📖 Overview

This repository contains the Stage 1 implementation of an e‑commerce order backend. The entire system lives in one codebase, one process, and one database. When a user places an order, the server synchronously processes payment, adjusts inventory, generates an invoice, and sends a confirmation email — all before returning a response.

The goal of this stage is to establish a realistic performance baseline and to understand the pain points that justify moving to an event‑driven microservices architecture in later stages.

⁠🧱 Architecture (Layered Monolith)

┌────────────────────────────────────────────────┐
│                Docker Compose              │
│                                            │
│  ┌─────────────┐        ┌──────────────────┐  │
│  │  orders-app│        │   orders-db     │ │
│  │ (Node.js)  │ ◄────► │ (PostgreSQL 15) │  │
│  └─────────────┘        └──────────────────┘  │
│                                            │
└────────────────────────────────────────────────┘

Inside the orders-app container:

Client
  │  POST /orders
  ▼
Express Server
  ├── routes/orderRoutes.js
  ├── controllers/orderController.js
  └── services/orderService.js
        ├── paymentService.js     (mock – 500 ms)
        ├── inventoryService.js   (mock – 300 ms per item)
        ├── invoiceService.js     (mock – 400 ms)
        ├── emailService.js       (mock – 1000 ms)
        └── repositories/
              └── orderRepository.js

All business logic is layered (Controller → Service → Repository). Everything is blocking — the HTTP request waits for every step to finish.

⁠🔧 Technology Stack

⁠🚀 Running the Project

⁠Prerequisites

• Docker Desktop⁠ (or Docker Engine + Docker Compose)
• curl (or any API client)

⁠1. Clone and start

git clone <your-repo-url>
cd order-system
docker compose up --build

⁠2. Verify it's running

curl -X POST http://localhost:3000/orders \
  -H "Content-Type: application/json" \
  -d '{
    "userId": 1,
    "items": [
      {"productId": "A1", "quantity": 2},
      {"productId": "B2", "quantity": 1}
    ],
    "email": "[email protected]"
  }'

Response (after ~2.5 seconds):

{
  "id": 1,
  "user_id": 1,
  "items": [
    {"productId": "A1", "quantity": 2},
    {"productId": "B2", "quantity": 1}
  ],
  "total_amount": "30.00",
  "status": "CONFIRMED",
  "created_at": "2026-07-06T08:10:00.000Z"
}

⁠3. Run the load test

# Install autocannon globally (only once)
npm install -g autocannon

# Execute the test
node load-test.js

⁠📊 Performance Baseline (Stage 1)

Load test configuration: 10 concurrent connections, 10 seconds, POST /orders

⁠⚠️ Known Architectural Smells

1. Tight coupling – The order service directly depends on every other domain (payment, inventory, etc.). Changing one requires changes to the monolith.
2. Slow user experience – Non‑critical tasks (invoice, email) block the HTTP response.
3. Poor fault isolation – An error in the invoice generator can fail the entire order, even if payment was already taken.
4. No scalability – Scaling the app horizontally still leaves each instance stuck waiting for the same slow mock operations.

These issues motivate the transition to Stage 2: Event‑Driven Microservices, where work is offloaded to background services via RabbitMQ, dramatically cutting user‑facing latency.

⁠📁 Project Structure (Stage 1)

order-system/
├── docker-compose.yml
├── Dockerfile
├── package.json
├── .env
├── load-test.js
├── README.md
└── src/
    ├── server.js
    ├── config/
    │   └── db.js
    ├── controllers/
    │   └── orderController.js
    ├── services/
    │   ├── orderService.js
    │   ├── paymentService.js
    │   ├── inventoryService.js
    │   ├── invoiceService.js
    │   └── emailService.js
    ├── repositories/
    │   └── orderRepository.js
    ├── models/
    │   └── order.js
    └── routes/
        └── orderRoutes.js

⁠📈 Roadmap (this is Stage 1 of 3)

• Stage 1 (this repo) – Monolith with layered architecture & synchronous processing.
• Stage 2 – Event‑driven microservices: split into Order, Payment, Notification services + RabbitMQ. HTTP returns instantly, work continues asynchronously.
• Stage 3 – CQRS: add a Redis read model and projections for ultra‑fast order dashboards.

⁠🤝 Contributing

This is a personal learning project, but feedback and suggestions are welcome! Open an issue or a pull request if you spot improvements.

⁠📄 License

MIT — feel free to use it for your own learning.