fahadbinsiddique/e-commerce-ordering-payment-system

Purpose and Entry Points

Production-style e-commerce system: Django REST API plus Next.js storefront. Backend HTTP entry points are routed through backend/config/urls.py, served via backend/config/asgi.py or backend/config/wsgi.py; Django commands start at backend/manage.py. The frontend uses Next.js App Router from frontend/app/layout.jsx and frontend/app/page.jsx.

Client, Session, and API Boundary

The Next.js client provides catalog, cart, checkout, order/payment history, and admin-facing pages. Route protection is enforced at the frontend edge by frontend/middleware.js. Zustand maintains browser-side authentication and cart state in frontend/store/auth-store.js and frontend/store/cart-store.js; API calls are centralized through frontend/lib/api.js and domain service modules such as frontend/services/paymentService.js.

Identity and Catalog Domain

JWT authentication is implemented by the accounts API, centered on the custom user model and serializers/views: backend/accounts/models.py, backend/accounts/views.py, backend/accounts/urls.py. Categories form a hierarchy used by catalog and recommendation traversal; products support CRUD plus filtering/pagination. Core boundaries are backend/categories/models.py, backend/products/models.py, and backend/products/views.py. Administrative writes are restricted while storefront reads feed product pages and order creation.

Order Creation and Pricing

Order APIs receive cart lines, persist orders and price-snapshotted order items, and expose user order lifecycle operations. The order domain resides in backend/orders/models.py, backend/orders/views.py, and backend/orders/serializers.py. Total computation is deliberately separated into backend/services/order/order_calculator.py, using deterministic Decimal rounding rather than trusting client totals. This creates the boundary between mutable catalog pricing and immutable order pricing.

Payment Orchestration and Fulfillment

Payments are provider-neutral at the API/model layer (backend/payments/views.py, backend/payments/models.py) and delegated to a strategy abstraction (backend/services/payment/base.py, backend/services/payment/factory.py). Concrete Stripe and bKash integrations live in backend/services/payment/stripe.py and backend/services/payment/bkash.py. Checkout returns either Stripe client-confirmation data or a bKash redirect URL. Provider notifications enter backend/payments/webhooks.py; lifecycle handling marks payments/orders successful and invokes stock fulfillment.

Transaction Safety and External Services

Successful payment triggers exactly-once stock reduction through atomic, row-locked inventory logic in backend/services/stock/stock_manager.py. PostgreSQL is the production relational store; Redis backs recommendation caching. Stripe is an SDK/webhook integration with signature validation; bKash is a tokenized-checkout REST integration whose callback is re-verified server-side. Runtime settings separate development, production, and testing in backend/config/settings/base.py, backend/config/settings/production.py, and backend/config/settings/testing.py.

Recommendations and Deployment Topology

Recommendations traverse category relationships with DFS and cache category/result data in Redis, exposed through backend/recommendations/views.py and implemented in backend/recommendations/services.py. Docker Compose runs backend, PostgreSQL, and Redis via docker-compose.yml; the backend image is defined by backend/Dockerfile. The frontend is independently deployable to Vercel (frontend/vercel.json), while externally reachable webhook delivery may use ngrok.