# Food Ordering Backend (Engineering-Focused)
## Overview
This project is a **backend-only food ordering system** built to demonstrate **real-world backend engineering**, not feature quantity. The focus is on **correctness, safety, concurrency handling, and security** under realistic failure scenarios.
This is intentionally **not a full product** (no UI, no payments, no notifications). Every implemented feature exists to solve a concrete engineering problem.
---
## Core Engineering Goals
The system is designed to answer one question:
> Can this backend remain correct, safe, and consistent under retries, concurrent updates, misuse, and partial failures?
---
## Tech Stack
* **Runtime**: Node.js
* **Framework**: Express
* **Database**: MongoDB + Mongoose
* **Auth**: JWT (stateless)
* **Security**: Role-Based Access Control (RBAC)
* **Testing**: Postman (manual API testing)
---
## Domain Model
### Order State Machine
Orders move through a **strict state machine**:
```
CREATED → CONFIRMED → PREPARING → READY
↘ CANCELLED
```
Invalid transitions are **rejected at the database level**, not just in route logic.
---
## Key Engineering Concepts Implemented
### 1. Atomic State Transitions
Order status updates use **single atomic conditional updates**.
**Why:**
* Prevents race conditions when multiple requests hit the same order
* Guarantees only one valid transition can succeed
**Result:**
* No double-confirm
* No skipped states
* No inconsistent order history
---
### 2. Idempotent Order Creation
Order creation supports an **Idempotency-Key**.
**Problem Solved:**
* Network retries
* Double-clicks
* Client timeouts
**Behavior:**
* Same idempotency key → same order
* Duplicate requests do not create duplicates
---
### 3. Rate Limiting (Abuse Protection)
Selective rate limiting is applied to **mutation endpoints only**.
**Why:**
* Protects against spam and brute-force behavior
* Preserves system availability
**HTTP Response:**
```
429 Too Many Requests
```
---
### 4. JWT Authentication
Stateless authentication using signed JWTs.
* No sessions
* No server-side auth storage
* Token carries user identity + role
**Failure Modes Handled:**
* Missing token → 401
* Invalid token → 401
* Expired token → 401
---
### 5. Role-Based Access Control (RBAC)
| Role | Permissions |
| -------- | -------------------- |
| Customer | Create own orders |
| Kitchen | Update order state |
| Admin | Override transitions |
RBAC is enforced via middleware, not inline checks.
---
### 6. Audit Trail (History Log)
Each order maintains a **history array**:
* Previous state
* New state
* Who changed it
* Timestamp
**Why:**
* Debugging
* Accountability
* Observability
---
## API Summary
### Auth
* `POST /auth/signup` → Create user (one-time provisioning)
* `POST /auth/login` → Receive JWT
### Orders
* `POST /orders` → Create order (customer only, idempotent)
* `PATCH /orders/:id/status` → Update state (kitchen/admin)
* `GET /orders` → Read-only access
---
## Error Semantics
| Code | Meaning |
| ---- | --------------------- |
| 400 | Invalid input |
| 401 | Authentication failed |
| 403 | Forbidden (RBAC) |
| 409 | State conflict |
| 429 | Rate limit exceeded |
Errors are **intentional and meaningful**, not generic.
---
## What This Project Explicitly Avoids
* UI / frontend
* Payments
* Notifications
* OAuth / refresh tokens
* Microservices
These are **product features**, not core backend correctness concerns.
---
## What This Project Demonstrates
* Designing safe write paths
* Handling concurrency correctly
* Enforcing invariants at the data layer
* Building secure mutation APIs
* Thinking in failure scenarios
---
## How to Run
```bash
npm install
npm start
```
Use Postman/any other REST API client to interact with the API.
---