Duaba Architecture

How the Duabalabs products are organised and how they share infrastructure.

Product map

                          ┌──────────────────────────────┐
                          │   duabalabs.com (umbrella)   │
                          └──────────────┬───────────────┘
                                         │
   ┌────────────┬───────────────┬────────┴────────┬───────────────┬─────────────┐
   │            │               │                 │               │             │
┌──────┐  ┌──────────┐  ┌──────────────┐  ┌────────────┐   ┌────────────┐  ┌─────────┐
│Sellub│  │   DPS    │  │   3y3anaa    │  │   Proxy    │   │ Duabanti / │  │  TBD    │
│      │  │ (Parse-  │  │  (delivery)  │  │  Fidelity  │   │ Duabaforge │  │Logistics│
│      │  │ as-a-svc)│  │              │  │            │   │ /Connect   │  │         │
└───┬──┘  └────┬─────┘  └──────┬───────┘  └──────┬─────┘   └─────┬──────┘  └────┬────┘
    │          │               │                 │               │               │
    └──────────┴───────────────┴─────────┬───────┴───────────────┴───────────────┘
                                         │
                              ┌────────────────────┐
                              │  Shared infra      │
                              │  (Swarm + DBs +    │
                              │   secrets + auth)  │
                              └────────────────────┘

Shared building blocks

Layer	Tooling	Notes
Compute	Docker Swarm on Azure VMs	Per-product stacks; see Infrastructure
Datastores	Postgres (Sellub, Vendure), MongoDB (DPS, Parse)	Per-product, no cross-product DB sharing
Cache / queue	Redis	Shared cluster, per-product DB index
Object storage	Azure Blob	Per-product container
Edge / CDN	Netlify (landing + storefronts + docs), Cloudflare DNS
Payments	Paystack (cards, MoMo, bank)	Used by Sellub and Duabanti
Email	Resend (transactional), Mailchimp (marketing)
Auth	Per-product (Vendure for Sellub, Parse for DPS-hosted apps)	No SSO between products yet
CI/CD	GitHub Actions → ACR → SSH deploy	See Infrastructure → Deployment

Repository layout

The umbrella monorepo duabalabs/duaba uses Git submodules for each product. Top-level structure:

duaba/
├── apps/
│   ├── sellub/              ← submodule (server, dashboard, storefront)
│   ├── dps/                 ← submodule (server, dashboard, templates)
│   ├── 3y3anaa/             ← submodule (server, app, landing)
│   ├── proxy-fidelity/      ← submodule
│   ├── duabanti-landing/    ← submodule
│   ├── duabaforge-landing/  ← submodule
│   ├── duabaconnect-landing/← submodule
│   ├── tbdlogistics-landing/← submodule
│   ├── duabalabs-landing/   ← submodule
│   ├── automation/          ← n8n workflows shared across products
│   └── duaba-docs/          ← THIS docs site
├── packages/
│   └── dps-client/          ← shared @duabalabs/dps-client SDK
├── ci/                      ← shared CI scripts and Dockerfiles
├── docs/                    ← legacy docs (being migrated into duaba-docs)
└── tools/                   ← provisioning + admin scripts

How docs are aggregated

Each product owns the content for its own section under apps/duaba-docs/pages/<product>/. PRs to docs go through the same review as code.

Long-form runbooks and API specs typically live in the product’s own repo (under docs/); the umbrella docs link to them with edit-on-GitHub routes pointed at the source repo.

Where the lines are between products

Hard rule: no product talks directly to another product’s database. All cross-product data flows go through HTTP / GraphQL APIs or the shared event bus. This keeps deploys independent and makes it possible to spin a product down without breaking the others.

Cross-product flow	Mechanism
Sellub → DPS (storefront-as-a-service for sellers)	DPS Provisioning API
3y3anaa → Sellub (deliveries for marketplace orders)	Sellub Webhooks → 3y3anaa Dispatch API
Duabanti → Sellub (donation checkout)	Sellub Shop API
All → DPS (analytics events)	DPS Events ingress

Overview Overview