Identifying the technical gap
Many educational e-commerce applications simplify transaction handling, inventory consistency, and payment workflows. GlobalScart was built to explore the backend coordination these workflows require.
GlobalScart focuses on data integrity, API-driven architecture, and payment flow design.
Project Objectives
Design a scalable e-commerce backend architecture
Implement secure user authentication with OTP verification
Handle cart-to-order state transitions with data integrity
Integrate Razorpay payment workflows for order creation and payment-state management
Maintain clean frontend–backend separation
Build comprehensive admin analytics and monitoring
System Design
Browser Client
- •Static shop and admin interfaces
- •REST API consumption
- •Client-side form validation
- •Bearer-token requests
FastAPI Application
- •Customer and admin routers
- •JWT authentication and RBAC
- •Validation and domain orchestration
- •Request logging and error handling
Commerce Services
- •Cart and checkout workflows
- •Inventory reservation lifecycle
- •Order and payment transitions
- •Cancellation and stock release
PostgreSQL
- •Customer and product dimensions
- •Order, item, and payment facts
- •Inventory reservations
- •Audit and funnel events
Razorpay Boundary
- •Provider order creation
- •Signature confirmation
- •Webhook endpoint
- •Test-mode public integration
Analytics Layer
- •KPI snapshots: Revenue, Average Order Value, Order Conversion Rate, Customer Retention, Repeat Purchase %
- •Revenue and conversion funnel analysis
- •Customer journey event logging
- •Protected admin endpoints and KPI reporting
Data Flow Steps
User Authentication
User registers/logs in → OTP verification → JWT token issued
Product Discovery
Product data fetched via REST APIs with filtering and search
Cart Management
Cart persisted through backend APIs with client-side state synchronization.
Checkout Initiation
Checkout triggers order creation with address validation
Payment Processing
Razorpay payment intent generated for transaction
Order Completion
Order status updated based on payment response
PostgreSQL Database Dimensions and Facts
Customer, product, and payment lifecycles map to clean transactional and analytical tables.
| Table Name | Detail | Relation |
|---|---|---|
| dim_customer | Customer identity and geography | 1 → many orders |
| dim_product | Catalog, category, price, and cost | 1 → many order items |
| fact_orders | Order totals, status, and customer | parent of items and payments |
| fact_order_items | Quantity, price, tax, and revenue | joins orders to products |
| fact_payments | Provider, amount, and payment state | many payments → one order |
| order_inventory_reservations | Reserved, consumed, or released stock | order + product lifecycle |
API Design
Representative endpoints verified against the FastAPI routers
| Method | Endpoint | Responsibility |
|---|---|---|
| POST | /api/auth/login | Authenticate a customer and begin the OTP/JWT flow |
| GET | /api/customer/products | Browse and filter the product catalog |
| PUT | /api/customer/cart | Synchronize customer cart quantities |
| POST | /api/customer/checkout/start | Validate checkout, create an order, and reserve inventory |
| POST | /api/customer/orders/{order_id}/simulate-payment | Confirm or cancel an order based on payment simulation |
| POST | /api/payments/razorpay/confirm | Verify payment confirmation and finalize order state |
| GET | /api/admin/kpis/latest | Return protected operational KPI data |
Checkout State Machine
Order, payment, and inventory transitions
Razorpay is integrated in test mode to demonstrate payment intent creation, transaction handling, and checkout flow.
Key Decisions
REST APIs for frontend independence
Decoupled architecture allows independent frontend/backend development and future mobile app integration
Stateless backend for scalability
JWT-based authentication enables horizontal scaling without session storage dependencies
Razorpay over dummy payments
Payment gateway integration demonstrates external-service handling and checkout state transitions
Modular service architecture
Clean separation of routers, services, and database layers improves maintainability and future scalability.
Visual Showcase
Real Engineering Decisions
Inventory Consistency
Concurrent purchases could oversell stock.
PostgreSQL transactions with row-level locking.
Inventory remained consistent during checkout.
Request Validation
Malformed payloads caused checkout failures.
Pydantic request validation.
Consistent API contracts and cleaner error handling.
Authentication
Protecting customer and admin endpoints.
JWT-based authentication and RBAC.
Role-specific access control.
Boundaries & Learnings
Limitations
- •Public Render deployment is a portfolio demo without a production SLA
- •Razorpay live credentials and payment execution are disabled in the public demo
- •Demo OTP implementation used for portfolio demonstration. Production SMS/email delivery was intentionally excluded.
- •No automated email notifications implemented
- •UI not optimized for animations or advanced interactions
- •Mobile responsiveness limited to core workflows
Key Learnings
- •End-to-end transaction flow design from cart to order completion
- •Payment gateway integration challenges including webhook handling
- •API contract discipline and version management
- •Debugging async frontend-backend communication issues
- •Handling partial system completeness in demo environments
- •Building admin observability tools for business metrics