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.