StockFlow — Multi-Tenant Inventory & Order Management

Stock movements are append-only and are the source of truth. Running totals per product and warehouse are kept alongside them so a read is one indexed row rather than a sum over the whole journal.

That makes the totals a cache, so there is a reconciliation job that recomputes every total from the ledger and reports the drift. A test corrupts a total by hand and asserts the rebuild corrects it.

Confirming an order locks each stock row for update, in a deterministic order sorted by product id. Without the lock, two simultaneous confirmations read the same figure and oversell. Without the sort, two orders sharing products in a different sequence deadlock.

An integration test fires ten concurrent confirmations for six units each against ten units of stock and asserts exactly one succeeds.

A custom VPC with public and private subnets across two availability zones, ECS Fargate services for the API and the frontend behind a single ALB with path-based routing, and a WAF web ACL with managed rule groups. RDS Postgres and ElastiCache Redis sit in private subnets with credentials in Secrets Manager.

Terraform is split into modules with separate state and tfvars per environment, on an S3 backend using native state locking.

GitHub Actions authenticates to AWS through OIDC with three separate roles: a read-only role for plans on pull requests, an apply role reached only through a GitHub Environment, and a push role scoped to the two ECR repositories. No static AWS keys exist anywhere.

Pull requests run fmt, validate, tflint and checkov and post the plan as a comment. Merges to the staging branch apply automatically; production is gated behind a manual approval.

Staging was applied, verified end to end through the load balancer, then torn down to avoid running cost. The repository holds the Terraform, an architecture diagram drawn from the applied state, and console screenshots from the running environment.