page:blueprints:restaurants:order tracking:django

Restaurants: Order Tracking Using Django

Summary

A order tracking blueprint for restaurants built with Django on Ample. Domain schema:

• menu_items (sku, name, section, price, allergens, active): the menu as a SKU catalog;
• stock_movements (sku, delta, reason, moved_at): ingredient and prepared-item stock;
• orders (order_no, service_type, status, placed_at): dine-in, pickup and delivery orders;
• order_lines (order_no, sku, qty, modifiers): order contents;
• events (seq, record_type, record_id, kind, at): application-owned history written in the same transaction.

Public information: menu with allergens and prices, locations, hours and reservations contact, catering information.

Resource Requirements

• Primitive Compute
• Primitive PostgreSQL
• Primitive S3-compatible Object Storage

Infrastructure Requirements

• Compute: Apps run in isolated x86_64 Firecracker microVMs that auto-pause when idle and wake on request; sizes are the priced VM sizes.
• Postgres: Managed PostgreSQL runs in its own microVM and is auto-provisioned when an app needs a database and no DATABASE_URL is supplied.
• S3-compatible Object Storage: Buckets are S3-compatible with issued credentials; PutObject and GetObject are verified by canary.

Prerequisites

• A Django project (pip install into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template)
• A PostgreSQL driver reading DATABASE_URL (auto-provisioned when omitted)
• Bucket credentials from ample bucket create passed as encrypted S3_* environment variables

Workflow Steps

1. Model the restaurants domain: Create the tables menu_items, stock_movements, orders, order_lines, events.
2. Workflow step 1: Model orders with explicit status transitions and order lines.
3. Workflow step 2: Apply status changes transactionally and record an event per change.
4. Workflow step 3: Expose status history to authorized callers only.
5. Workflow step 4: Deploy and verify history and conflict rejection.
6. Deploy: Run the synchronous deploy once and read the result.
7. Verify: Run the pattern self-test(s) from the example and your own acceptance checks for the restaurants workflow.

Success Checks

1. App responds on its public URL
2. Transactional-workflows self-test from the example

Limitations

• The technical basis is verified with the pattern fixture; the restaurants schema and workflow were not executed as a separate application.
• Verified on the python-3.12 template.

Cost Estimate

• Currency: USD
• Monthly Amount: 10.0
• Components:
  • App server: 1 × s-1vcpu-1gb ($5.0)
  • Managed PostgreSQL database: 1 × s-1vcpu-1gb ($5.0)

Examples

• Django Pattern Fixture: Verified transactional workflows basis for this blueprint.

Next Actions

• Browse the catalog index
• Search published recipes by intent, stack and constraints
• Prepare a side-effect-free deployment plan for an authorized project