The Netorigo ecosystem — one admin, six modules

The word "ecosystem" is so worn out in the SaaS world that it has lost all meaning. We replaced it with specifics: the Netorigo ecosystem is where one admin interface (admin.netorigo.com) drives six backend modules, all in a unified tenant model. In this article we unpack what's actually under the hood, with a concrete order-flow example at the end.

The six modules

The six modules are not six microservices in the classic sense — not a "every module its own repo, its own database, its own deployment" sprawl. They are six functional boundaries inside one NestJS monorepo, each with its own database schema:

1. Catalog — products, categories, attributes, media, i18n translations. The products, product_translations, categories, tags table family.
2. Sales — orders, carts, quote requests, coupons. The sales_orders, cart_lines, quotes table family.
3. Inventory — stock, warehouses, receivings, reservations. The inventory_levels, warehouses, stock_movements table family.
4. Finance — invoicing, VAT filing, GL accounting. The invoices, payments, gl_entries table family.
5. Logistics — shipping, warehouse pick-pack, carrier API integrations. The shipments, pick_lists, carrier_quotes table family.
6. Travelium — travel products, bookings, allotment management. The travel_products, travel_bookings, allotments table family — a domain-specific extension alongside the classic ERP modules.

The sixth module already demonstrates that Netorigo is not a generic e-commerce platform but a domain-extensible ERP. Tomorrow a 7th module could be Education (courses, exams) — under the same admin, the same tenant model.

One tenant, many storefronts

The tenant is the shared legal entity (for instance "Netorigo Ltd."), which can use all six modules. Under one tenant multiple storefronts can run: netorigo.com, travelium.hu, nortinia.com, mediaorigo.hu and 9 more siblings. 13 storefronts, one tenant, six backend modules — this is the current reality.

Storefronts are CMS-editable from the admin: navigation menus, landing pages, category display order, SEO landings. But the product catalog is ONE. A SKU exists once in the Catalog module — which storefront it appears on is just a storefront_visibility flag.

Data flow: a travelium booking runs through

Concrete example. A buyer opens a "Barcelona 4 nights" product on travelium.hu and books it:

1. Catalog: the product detail page reads the travel_products table (by slug), translations (product_translations EN locale), stock-status placeholder.
2. Inventory + Travelium: queries the allotment (any free capacity on the chosen date).
3. Sales: the buyer adds to cart, fills in booking data (passenger names, dates). cart_lines gains a travel_metadata JSONB.
4. Checkout: price calculation (Finance module VAT logic), coupon check (Sales), payment (payment-provider integration handled by Finance).
5. Sales → Inventory: the sales_orders.confirmed event triggers an allotment reservation in the Travelium module (travel_bookings insert).
6. Finance: the shared invoice_generation queue creates an invoice and submits it to the NAV filing system.
7. Logistics: if a gift_voucher PDF accompanies the travel product, the Logistics queue prepares and emails it.
8. Travelium: 24 hours before the trip, the Travelium module's travel_reminders cron sends a reminder email.

One customer action — a booking — touched six modules, all under one tenant, one admin interface.

The key: no silos

In the classic "ERP + e-commerce + booking system" triad you have three different pieces of software, three different contracts, three different API integrations. In the Netorigo model it's one contract, one admin, one data flow — and the 6th module can become the 7th tomorrow without rebuilding the client from scratch. That is what we actually call an ecosystem.