Commerce-as-a-Service Platform

A robust, multi-tenant B2B Commerce-as-a-Service (CaaS) platform built with Rust and PostgreSQL. This platform provides merchants and developers the infrastructure to provision and run storefronts, manage catalogs, process orders, handle payments, and coordinate fulfillment as a service.

Architecture & Microservices

The platform is designed around an event-driven microservices architecture using Redis/RabbitMQ for pub-sub and Saga pattern orchestration.

• order-service: Orchestrates a distributed Saga pattern coordinating payment and inventory services, executing compensating transactions on failure, and handling tax and pricing calculations.
• inventory-management: Uses asynchronous background workers to handle stock reservations, time-to-live (TTL) on reserved items, and responds to distributed Saga events.
• supplier-management: Implements a dynamic commission tier engine that evaluates a vendor's expected monthly volume during onboarding to assign custom pricing tiers (e.g., Pro, Enterprise).
• logistics: Contains custom routing algorithms to automatically determine the most efficient warehouse to fulfill shipments.
• analytics: Dynamically constructs complex SQL queries to aggregate and window time-series metrics based on merchant requests.
• payments: Handles complex external integrations, including Stripe webhook validation, automated refunds, and payment transfers.
• tenant-management: Manages B2B multi-tenancy configurations, handling dynamic feature flags, API key generation/revocation, and custom webhook rate-limit configurations per tenant.
• user-management: Implements JWT authentication, Role-Based Access Control (RBAC), password resets, and email verification workflows.
• product-catalog: Handles bulk product creation and secure direct-to-cloud asset uploads (e.g., generating signed Cloudinary upload tokens).
• notifications: Manages granular user notification preferences and multi-device push notification registrations.
• api-gateway: Acts as a central proxy handling tenant resolution and global request routing across the microservices.

Tech Stack

• Backend: Rust (Actix-Web)
• Database: PostgreSQL (SQLx)
• Event Bus: Redis & RabbitMQ
• Authentication: JWT
• Payments: Stripe Connect

Design Philosophy

The administration UI follows a dual-register design philosophy:

1. First-run onboarding: A warm, guided checklist experience to help merchants connect payment providers, add products, and configure storefront domains.
2. Day-30 operations: A high-density, dark-mode-first operator environment emphasizing speed, bulk actions, and deep financial data trust (modeled after Stripe and Shopify Polaris).

For more detailed design principles and UI instructions, refer to AGENTS.md and CLAUDE.md.

Pricing Tiers: Free vs Growth vs Enterprise

The CaaS platform enforces strict multi-tenant boundaries and dynamically assigns resources based on the tenant's subscribed tier:

1. Free Tier

• Database Architecture: Uses the Shared PostgreSQL Connection Pool. All Free tier merchants reside in the shared physical database schema, isolated entirely via Row-Level Security (RLS) and logical enant_id application segregation.
• Rate Limits (Redis): Heavily throttled via the RateLimiterMiddleware.
• Custom Metadata (Configurable Fields): Basic scalar type validation (string, integer, �oolean) for custom fields.
• Support: Community support only.

2. Growth Tier

• Database Architecture: Still utilizes the Shared PostgreSQL Connection Pool with RLS isolation.
• Rate Limits (Redis): Relaxed rate limits allowing higher API throughput for high-volume sales days.
• Custom Metadata (Configurable Fields): Full advanced validation support including regex constraint matching, enums, IP addresses, datetimes, and complex schema validation.
• Analytics: Access to the �nalytics service with wider time-windows for data aggregation.

3. Enterprise Tier

• Database Architecture: Uses an Isolated PostgreSQL Connection Pool. Enterprise tenants receive physically isolated database infrastructure with dedicated connection strings routed dynamically by the DynamicPoolRouter. This ensures absolute compliance, data sovereignty, and prevents noisy-neighbor problems.
• Rate Limits (Redis): Custom, high-capacity SLA limits tailored to the organization.
• Integrations: Access to premium webhook event streams (via supplier-management and enant-management), custom SAML/SSO integration, and fully white-labeled domains.
• Dedicated Infrastructure: Independent microservice scaling nodes can be logically partitioned via Kubernetes if required.

Hardcoded Feature Limits (Enforced in Code)

The backend natively enforces feature availability, rate limiting, and capacity constraints across three strictly separated tiers:

• Free Tier: Geared towards small-scale merchants exploring the platform.
  • Constraints: Strictly limited to 100 monthly requests, a maximum of 3 staff users, and a catalog limit of 50 products.
  • Features: Excludes advanced capabilities like Multi-currency pricing and Advanced Webhooks.
• Growth Tier: Designed for scaling businesses with complex operational needs.
  • Constraints: Increased limits of 10,000 monthly requests, up to 25 staff users, and a catalog limit of 5,000 products.
  • Features: Includes full access to Advanced Webhooks (supplier webhooks) and Multi-currency support.
• Enterprise Tier: Enterprise-grade infrastructure for high-volume, global operations.
  • Constraints: Unlimited requests, users, and products (enforced as u64::MAX / i64::MAX).
  • Features: Access to all advanced capabilities, plus custom Service Level Indicators (SLIs).

Note: The enforcement of these limits is baked directly into the route handlers of the microservices (e.g., product-catalog strictly rejects product creation requests when a tenant hits their max_products threshold, and supplier-management intercepts advanced webhook setup attempts for Free-tier tenants).