The platform is the product.
Robnu's foundation is multi-tenant from day one — Org → Seller → SellerUser → MarketplaceAccount with generic FK targets and per-marketplace satellites. AWS S3 with per-seller KMS aliases. AWS SQS + BullMQ hybrid queueing. Postgres RLS as defense in depth. Every other Robnu surface — Process, Reconciliation, Claims, RobnuAI — sits on this.
- Seller is the tenant root. SellerUser is a teammate. MarketplaceAccount is a connection. Multi-account is free.
- AWS S3 with SSE-KMS using per-seller KMS aliases when AWS_S3_PER_SELLER_KMS=true.
- AWS SQS FIFO + Standard for marketplace dispatch; BullMQ for cron-style sweeps.
- Postgres RLS on seller_id is enforced via withSellerScope — defense in depth, always on.
The five surfaces of the platform.
Multi-tenant model
Org → Seller → SellerUser → MarketplaceAccount. Super-admin impersonation built in.
Marketplace adapters
Generic MarketplaceAccount + per-marketplace satellites. One registry, four adapters.
Storage
AWS S3 with SSE-KMS, per-seller KMS aliases. Raw payloads queryable via Glue + Athena.
Queues
BullMQ for cron sweeps. AWS SQS FIFO + Standard for marketplace dispatch and execution.
RLS isolation
Postgres Row-Level Security as defense in depth on seller_id. Always-on, no opt-out.
Adding a marketplace doesn't ripple through the schema.
The generic MarketplaceAccount parent means every leaf table — orders, shipments, returns, payouts, schedules, listings — FKs to the same place regardless of marketplace. New marketplaces ship as a new Marketplace row + a new satellite table + an adapter implementation in the registry. Zero changes to leaf tables.
- · AJIO is live; Meesho, Amazon, Flipkart adapters are scaffolded.
- · Adapter contract: syncOrders, syncReturns, syncPayouts, pushInventory, fullProcessing.
- · Registry dispatch is by Marketplace.code, not class identity.
Honest answers about the foundation.
Two reasons. First, sellers asking 'is this safe' deserve a real answer instead of a 'we take security seriously' page. Second, partners and integrators asking 'how does this scale' need the architectural shape, not a brochure.
Seller is the unit of business — the tenant root. SellerUser is each human teammate with an RBAC role (OWNER | ADMIN | OPERATOR | FINANCE | VIEWER). MarketplaceAccount is each connection — multi-account is free; one seller can have N AJIO accounts and M Meesho accounts on the same plan.
Each marketplace has different identifiers and credential shapes. The generic MarketplaceAccount table is the FK target for everything (orders, shipments, returns, payouts, schedules, listings). 1:1 satellite tables (ajio_account_details, meesho_account_details, amazon_account_details, flipkart_account_details) carry the marketplace-specific fields with strong typing.
BullMQ is great at cron-style sweeps inside Node. AWS SQS is great at durable, observable, per-account FIFO dispatch with DLQ semantics. The hybrid uses each for what it does best — see /platform/queues for the layout.
Application-layer scope assumes every code path remembers to filter by seller_id. RLS makes the database refuse to return cross-tenant rows even if a code path forgets. Defense in depth, not redundancy.
The platform is what makes everything else possible.
Read each surface in detail, then start using the product that sits on top.