Multi-vendor Commerce Architecture

One Pasal is a multi-vendor commerce platform: independent vendors list products into a shared catalog, and a single checkout flow has to resolve inventory and orders across all of them. As lead backend developer, Nitesh Dhungana is responsible for the backend team, the database architecture, the overall project structure, and how the system is deployed.

• Multiple vendors operate against shared catalog and order data, so schema and permission boundaries have to prevent one vendor's data from leaking into another's view.
• Inventory and pricing change frequently and have to stay consistent between catalog browsing and checkout.
• The backend team is shared across features, so the architecture has to stay legible to engineers who did not design it.

• Backend technical leadership for the team building the platform
• Database architecture covering vendors, products, inventory, and orders
• Overall project structure and module boundaries
• Deployment planning and infrastructure scaling
• Cross-team collaboration with product and frontend

The platform follows a layered Django service: HTTP requests are handled by Django REST Framework views, business rules live in a service layer rather than in views or serializers, and anything that does not need to block the response — order confirmation emails, inventory recalculation, vendor notifications — is pushed onto Celery workers backed by Redis. PostgreSQL is the single source of truth for vendors, catalog, inventory, and orders, with Nginx and Docker used to keep the deployed environment reproducible.

• Modeled vendors, products, and inventory as distinct, explicitly related entities rather than overloading a single product table, so vendor-specific rules do not leak into shared catalog logic.
• Kept order-affecting side effects (notifications, inventory adjustments) out of the request/response cycle by routing them through Celery, so checkout latency is not coupled to how many downstream actions an order triggers.
• Used Docker and Nginx to standardize the deployment environment across development and production, reducing the chance that a service behaves differently outside the machine it was built on.

• Inventory and order state changes are treated as operations that can fail or be retried, rather than assumed to succeed once triggered.
• Background jobs are isolated from the request path, so a slow or failing side effect (such as a notification) does not block or fail a checkout.
• Database structure enforces vendor boundaries so a bug in one vendor's flow is less likely to affect another vendor's data.

• Django
• Python
• PostgreSQL
• Redis
• Celery
• Docker
• Nginx

• In a multi-vendor system, the hardest boundaries to get right are the ones that look like a single shared table until a second vendor exposes the assumption.
• Deployment reproducibility matters as much as application code once more than one engineer is shipping to the same infrastructure.