Multi-Vendor E-Commerce Marketplace
A marketplace with money moving between buyer, seller and platform. In systems like this the most expensive mistake is a money mistake, so most architectural decisions were made around correctness and auditability. Interface screenshots are withheld out of client confidentiality; the account here stays at architecture level. The system can be demonstrated in person on request.
Four critical decisions
Multi-vendor pivot
The buyer's single payment is split automatically into per-seller sub-orders. Each seller sees only their own order; shipping, returns and earnings all run through that sub-order. Start with a single-order model and this separation cannot be retrofitted.
Double-entry ledger
Seller earnings are not held in a single balance field. Every movement is its own row: a successful payment writes a CREDIT, cancelled logistics writes an automatic DEBIT. The balance is summed each time and never overwritten. Accounting's centuries-old method gives you auditability for free.
Payment provider abstraction
Payment logic is fully separated from the view layer behind an Adapter pattern. Swapping provider leaves business logic untouched. Synchronous verifications are guarded by a double-spend lock and asynchronous webhooks by an idempotency lock, so payment state stays consistent even if the browser is closed mid-checkout.
Single-schema API
A custom DRF renderer and exception handler make every response, 200 or 500 alike,
come back in the same JSON schema: success / data / error.
There is no case left where the frontend has to guess the response shape.
Infrastructure
Media uploads are streamed to Cloudflare R2 (S3-compatible) through boto3 without ever touching server disk, which keeps the application stateless and horizontally scalable. Delivery runs on six services under Docker Compose, with CI on GitHub Actions.