MLM Platform Architecture for NOVA Collective
Denisa Georgiana Voicu
Architecting a multilevel marketing platform
NOVA Collective
An independent architecture case study connecting product commerce, purchase-generated points, partner networks, qualification rules and commission accounting.
This case study is based on a complete MLM platform I designed and built. To protect client confidentiality and comply with NDA obligations, names, products, sensitive data, and aspects of the software architecture have been modified for this presentation.
Project overview
NOVA Collective sells skincare products through a storefront and a network of independent partners. A customer purchase does more than create an order: it establishes sales attribution, generates qualifying points, contributes to network performance and creates potential commission obligations.
NOVA Collective Website & Mobile PWA Version
I developed this concept to show how I translate a complex business model into a coherent software architecture. The focus is on the relationships between systems and on the rules that keep their behavior predictable when payments, returns, ranks and payouts change.
The architectural challenge
A single purchase can affect several people and several records. The customer needs an accurate order history. The referring partner needs understandable sales and earnings. Upline partners need the correct volume and commission attribution. Operations and finance need to explain every adjustment.
The central design question is how to preserve that shared history without treating points, rank, account access and money as interchangeable values.
My role and scope
Software architecture, domain modeling, business-rule design, permission modeling and experience planning. I defined a single-brand, EUR-only first release with one sponsor per partner, monthly rank qualification and commissions across three beneficiary positions. The proposed implementation and validation plan are documented separately from the design decisions.
2. Separate access from network status
I began with the decisions each person needs to make. This establishes both the product experience and the authorization boundaries before defining screens.
Roles and permissions table - Software architecture
Three independent dimensions
A role defines what an account may do. A rank defines which compensation rules a partner qualifies for. Network depth describes a relationship between two partners. A Leader rank does not grant administrative permissions, and a staff administrator does not automatically earn commissions.
Authorization follows the record
The proposed API checks both the requested action and the caller’s relationship to the record. Access is denied unless a policy grants it. A partner’s access to a branch summary does not grant access to every order, address or payout in that branch. The same rules apply to downloads and background exports. This combines role permissions with ownership and relationship checks. [1]
Staff controls
Privileged accounts use multifactor authentication. Rule publication, refunds, exports and payout approvals record the actor, time, reason and affected records. Financial corrections are explicit operations with approval, rather than editable balance fields.
3. Model the business as connected entities
Products are first-class entities because their commercial rules influence everything downstream. User roles belong in the access model; they do not replace the entities that represent transactions, relationships and financial obligations.
The domain model - Software architecture
The essential relationship
An Order contains OrderItems; each item references a SKU and freezes its relevant rule values. A captured Payment enables pending PointEntries and CommissionEntries. A Refund creates linked adjustments. PayoutAllocations connect approved commission obligations to an actual payout.
Customer identity, direct-partner attribution and sponsor ancestry are recorded separately. This prevents a later profile edit from changing who was entitled to a historical transaction.
4. Connect products and purchases to points
A product is both a customer-facing item and an input to the business rules. Each SKU carries its selling price, eligibility flags, point multiplier and effective rule version. Inventory availability is checked at checkout; reservation and fulfillment remain part of the commerce module.
Define the eligible purchase value
For this concept, the calculation starts with the net product amount after discounts, excluding tax and shipping. Order-level discounts are allocated to the lines in cents so their sum matches the original discount. Each line preserves that allocation and its product-rule version.
Qualifying points are calculated from the eligible line value multiplied by the SKU’s point rate, then summed across the order. Values use fixed decimal precision. Monetary values use integer cents. Point precision and rounding are part of the versioned rule.
From products to points - MLM software architecture
Keep four measures distinct
Revenue measures the eligible product sale in euros. Personal volume measures the qualifying points credited to the directly attributed partner. Group volume measures qualifying points from descendant partners. Commission measures a monetary entitlement calculated from eligible sales revenue. Eighty points do not mean eighty euros.
Make attribution explicit
A retail customer uses a valid partner referral at checkout. The direct partner and sponsor path are locked when payment is captured. A purchase without partner attribution is a house sale and creates no network rewards. In this concept, partner self-purchases remain ordinary commerce orders and do not generate qualifying volume or commissions.
Record movements rather than edit totals
Payment capture creates pending point entries. They become recognized volume after fulfillment and a fictional 30-day return hold, provided no dispute is open. Returns create linked reversals. Period totals are derived from this history; the interface never writes a point balance directly. These points cannot be spent or withdrawn.
5. Define the network and qualification rules
I chose a unilevel network: each partner has one sponsor and may sponsor multiple partners. A retail customer remains outside that partner tree. This keeps customer ownership, partner ancestry and commission position explicit.
Personal and group volume
The directly attributed partner receives an order’s qualifying points as personal volume. Each ancestor receives that same source volume once in its group-volume projection. A partner’s group volume excludes their own personal volume. These projections are not additional company sales and must never be summed as company revenue.
For the first release, a sponsor link is fixed after the partner’s first qualifying transaction. Cycle checks reject self-sponsorship and circular paths. The capture-time path is retained for historical calculations; commission depth is bounded even when the network itself is deeper.
Rank qualification - Multilevel marketing software architecture
All ranks require an enabled partner account. The thresholds and rates are invented to demonstrate the architecture; they are not commercial performance claims.
Avoid circular qualification
Monthly boundaries use UTC. At the start of each month, the system evaluates the previous month’s recognized volume and publishes a rank snapshot for the new month. New partners begin at Partner. The rank effective at payment capture determines commission eligibility for that order; a later promotion does not reprice it.
Volume is recognized in the period when the return hold expires, rather than backdated to the sale. Before a period closes, the worker must finish eligible events through a recorded processing cutoff. Later corrections enter the next open period and retain a link to the original source. Closed rank snapshots remain unchanged.
Explain every qualification decision
The proposed partner experience shows personal and group volume separately, the period being evaluated, the next threshold and the effective date of the next rank. A qualification record stores the rule version, totals and decision so support can explain why a rank was assigned.
3. Calculate commissions and control payouts
The commission engine uses commissionable net revenue, the captured sponsor path and the rank snapshot effective at capture. Point multipliers affect qualification volume; they do not silently change the cash commission base.
Commission rules - MLM Software Architecture
The plan uses fixed positions without compression. If a beneficiary is missing, ineligible or suspended at capture, that position earns nothing; the next ancestor does not move into it. Enrollment itself produces no points or commission.
Separate entitlement from available money
A captured order creates provisional commission entries. Delivery plus the 30-day hold makes the remaining entitlement eligible for finance approval, provided the order is not disputed. Approved amounts enter a monetary journal; only approved, unreserved amounts can be allocated to a payout.
Pending, approved, reserved, paid and reversed are distinct states. Payout reservation and journal updates occur in a database transaction. Payout credentials are provider-managed references, and staff approval is separated from the initiating request.
Preserve the original calculation
Each entry stores the order and source-line allocations, recipient, network position, eligible amount, rate, rule version and rank snapshot. Commission totals are rounded to cents; allocation and cumulative-refund rules conserve the original amount. Refund effects cannot exceed the original entitlement.
Handle refunds across the lifecycle
A refund before approval reduces pending entitlements. A refund after approval creates compensating journal entries. If money has already been paid, a recoverable debit is recorded against future earnings and displayed explicitly; the platform does not silently withdraw funds from a partner’s bank account.
Treat provider uncertainty as a state
A payout has a stable idempotency key and retains its provider reference. If submission times out, its status becomes unknown and is reconciled before any retry. A failed payout releases its reservation once. A successful payout is marked paid only after verified provider confirmation.
7. Follow one purchase through the system
Illustrative scenario: a retail customer buys the €60 Daily Serum and €40 Refill Moisturizer through Ava, an active Partner. Ava’s sponsor Ben is a Builder; Ben’s sponsor Cara is a Leader. All three are eligible at payment capture. Prices below exclude tax and shipping, and no discount is applied.
Network marketing Software Architecture
A partial refund before the hold expires
The customer receives a €30 partial refund against the serum line. That line’s original point rate is 1.00, so the system reverses 30.00 pending points. The retained product value is €70.00 and the remaining qualification volume is 50.00 points.
Refund rules - Software architecture
At maturity and approval
After delivery and the hold, the remaining 50.00 points become Ava’s recognized personal volume and contribute once to each ancestor’s group volume for that month. The remaining €11.90 becomes eligible for finance approval and subsequent payout allocation. Replaying either payment or refund notifications must leave these totals unchanged.
This walkthrough makes the architecture reviewable: the same source lines explain the customer’s refund, the partner’s points, the network’s volume and the remaining money owed.
8. Choose an architecture that can be operated
The proposed starting point is a modular monolith with a separately running worker. Domain boundaries remain explicit inside one application codebase, while a shared relational database supports transactional financial updates. This keeps initial deployment and debugging manageable.
NOVA Platform Architecture - MLM Software
Logical component map. Arrows indicate integration relationships, not an exact execution sequence. Domain modules remain in one application; the worker runs background jobs.
The durable transaction boundary
A database transaction records the payment state and an outbox event together. A worker publishes committed events; consumers record an event receipt and the resulting business changes in the same transaction. The queue may redeliver, so each effect also has a unique business key. This avoids treating message delivery as an exactly-once guarantee. [2]
Proposed implementation
TypeScript with React for the interfaces; a Node.js application API and worker; PostgreSQL for authoritative records; managed identity and a payment-provider adapter. A queue can transport work, and object storage can hold media and scoped exports.
9. Design for exceptions and verifiable behavior
A reliable specification needs to explain what happens when the normal sequence breaks. The validation plan focuses on financial invariants, access boundaries and the ability to reconstruct a calculation.
Failure scenarios - Software architecture
Consistency and observability
Sensitive operations such as payout reservation require appropriate locking or serializable transactions with retry handling; a transaction alone does not resolve every concurrency conflict. [3] Unique constraints also protect source-event and beneficiary allocations.
Dashboards use derived projections with a visible update time. Payout decisions read authoritative ledger records. Operations can inspect queue age, unprocessed events, reconciliation discrepancies and failed jobs. Correlation identifiers link an order, its payment, points, commissions and eventual payout.
Validation plan
The next implementation stage would test money conservation, duplicate and out-of-order notifications, discount and refund rounding, period closure, authorization and recovery after failure. The arithmetic walkthrough is checked; software integration, security and load testing have not been executed because this deliverable is a concept blueprint.
10. Make the rules understandable in the product
The interface should explain the model in the language of the person using it. A clear experience depends on the same distinctions that make the architecture consistent.
Skincare Multilevel marketing concept design
Customer experience
The storefront shows products, price, referral attribution, payment status and order tracking. Customers can request a return and see its effect on their order. They do not need access to partner calculations to complete a purchase.
Skincare storefront - Software architecture
Partner experience
The portal separates personal volume, group volume, current rank, pending commission and available earnings. A transaction detail explains the source order, applicable rule and any reversal. Rank progress shows both the qualification period and the date a new rank would take effect.
Partner Dashbaord - MLM Software Development
Rank graph MLM Software Architecture & Development
Operations and finance experience
Operations sees fulfillment, return cases and processing exceptions. Finance sees provisional and approved liabilities, payout reservations, adjustments and reconciliation. Support can follow a permitted transaction timeline without being given unrestricted financial authority.
Finance workspace - Software Architecture
Decisions and tradeoffs
Decisions & Tradeoffs - Software architecture
Design outcome
The result is a connected architecture blueprint: a domain model, a permission model, explicit commerce and compensation rules, a worked refund scenario and a validation plan. Each figure in the proposed product can be traced to a source transaction and a rule version.
This case study demonstrates my approach to software architecture: turning business complexity into defined relationships, state transitions and reviewable decisions. Production performance and commercial outcomes remain outside the scope of this concept.
The architecture roadmap - Multilevel Marketing Software architecture
Every order has a source. Every point has a reason. Every commission can be explained.
Relevant expertise
Software Architecture · Systems Design · Domain Modeling · Database Design · Business Logic · Authorization Design · Product Design
Like this project
Posted Oct 17, 2026
An independent software architecture concept for a commerce-led multilevel marketing platform. MLM Platform Architecture
