Chapter 2: Understanding Business Models

Why This Exists

Software architecture does not exist in a vacuum; it exists to serve a business. The way a company makes money—its business model—dictates the entire technical foundation of its e-commerce platform. A system designed to sell single t-shirts to teenagers requires a completely different database schema, checkout flow, and API structure than a system designed to sell heavy machinery in bulk to construction companies. Understanding business models exists so architects can build software that actually supports how the company operates.

Real World Problem

Imagine a team of developers spends six months building a beautiful e-commerce site. It has a slick shopping cart and integrates perfectly with Stripe for credit card payments. On launch day, the sales team reveals a critical detail: "Our customers are hospitals. They buy in bulk, they need to request quotes, negotiate prices, and they pay via 90-day invoices, not credit cards."

The entire architecture is useless because it assumed a B2C (Business-to-Consumer) model for a B2B (Business-to-Business) company. The real-world problem is bridging the gap between how money changes hands and how the code processes it.

Everyday Analogy

Think about buying coffee.

B2C (Business-to-Consumer): You walk into a coffee shop, look at the menu, pay $4 with your card, and get a coffee. Everyone pays the same price.
B2B (Business-to-Business): The coffee shop owner buys 500 bags of coffee beans from a farm. The price isn't on a menu; it's negotiated based on volume. The farm ships the beans and sends a bill that the shop has 30 days to pay.
Marketplace: A farmer's market. The market organizer doesn't own any coffee; they just rent space to different coffee vendors and take a small fee from each sale.

Beginner Explanation

In e-commerce, there are four primary business models:

B2C (Business-to-Consumer): Companies selling directly to individual shoppers (e.g., Target, Nike). The price is fixed, the checkout is simple, and payment is immediate.
B2B (Business-to-Business): Companies selling to other companies (e.g., a paper supplier selling to Dunder Mifflin). Orders are large, prices are often customized per client, and payment happens later via invoice.
C2C (Consumer-to-Consumer): Individuals selling to other individuals (e.g., eBay, Craigslist).
Marketplaces: A platform that connects multiple buyers and sellers (e.g., Amazon, Etsy). The platform makes money by taking a commission (a percentage) of the sale.

Intermediate Explanation

The business model directly impacts the logic inside your application.

In a standard B2C system, the Price is an attribute of the Product. If the shirt is $20, it's $20 for everyone.

In a B2B system, Price is dynamic. The price of a laptop might be $1,000 for a regular business, $800 for a non-profit, and $750 for a client who buys more than 100 units a year. The code must look at the User making the request, fetch their Company_Tier, apply volume discounts, and then calculate the cart total. Furthermore, the checkout button might not say "Pay Now"—it might say "Request Quote."

Advanced Explanation

At scale, architectures often blend these models, leading to massive complexity. Take a B2B2C Marketplace like a food delivery app (e.g., UberEats).

The platform must handle:

B2C Logic: The end consumer browsing the menu and paying via credit card.
B2B Logic: The restaurant receiving the order and managing their menu.
Multi-Party Financial Routing: When a user pays $30, the system cannot just put $30 into the platform's bank account. It must dynamically split the payment: $20 to the restaurant, $5 to the driver, and $5 to the platform (commission). This requires complex escrow and payout architectures, often heavily regulated by financial laws.

Real World Example

Alibaba vs. AliExpress: Alibaba group runs two massive, but architecturally distinct platforms.

Alibaba.com is a pure B2B platform. You can't just buy one phone case; you must request a quote for 10,000 phone cases from a factory in Shenzhen. The platform focuses on messaging systems, quoting engines, and trade assurance.
AliExpress is their B2C equivalent. You can buy a single phone case for $2, add it to your cart, and pay instantly. The platform focuses on fast checkouts, consumer recommendations, and individual shipping logistics.

Architecture Design

Here is how a B2B flow differs architecturally from a B2C flow:

graph TD
    subgraph B2C Flow
    C_B2C[Shopper] --> Cart_B2C[Shopping Cart]
    Cart_B2C --> Check_B2C[Standard Checkout]
    Check_B2C --> Pay_B2C[Credit Card Processing]
    end

    subgraph B2B Flow
    C_B2B[Corporate Buyer] --> Quote_Engine[Quoting Engine]
    Quote_Engine --> App_Service[Approval Workflow]
    App_Service --> PO_Gen[Purchase Order Generation]
    PO_Gen --> Inv_Sys[Invoicing System]
    Inv_Sys --> Net30[Net-30 / Net-60 Payment]
    end

Database Design

To support a B2B pricing model, your database cannot rely on a simple price column on the products table. You need a highly relational structure:

companies table: Stores the corporate client.
price_tiers table: Defines discount groups (e.g., Gold, Silver).
company_contracts table: Links a company to specific negotiated terms.
product_prices table: Maps a product_id and a tier_id to a specific price.

When a B2B user queries a product, the SQL join must look up their company, check their contract tier, and fetch the corresponding price.

API Design

The APIs exposed will differ drastically based on the model:

B2C API Example: POST /api/v1/checkout/charge Payload: { cart_id: 123, payment_method_id: "pm_abc" }

B2B API Example: POST /api/v1/quotes/request Payload: { company_id: 456, items: [...], requested_discount: 10% }

Marketplace API Example: POST /api/v1/payouts/split Payload: { order_id: 789, vendor_id: 12, commission_rate: 0.15 }

Production Considerations

Pricing Engine Latency: In B2B, calculating the price of a 500-item cart where each item has unique tiered pricing rules is computationally heavy. This can easily cause latency. Results must be aggressively cached per customer.
Invoice Generation: Generating hundreds of thousands of PDF invoices at the end of the month requires asynchronous background workers. It cannot be done synchronously on the web server.

Security Considerations

Data Isolation: In a marketplace, Vendor A must never be able to query the API and see Vendor B's sales data. Multi-tenant architectures require strict Row-Level Security (RLS) at the database level.
Authorization: In B2B, an employee might have permission to create a cart, but only their Manager has permission to approve the Purchase Order. Role-Based Access Control (RBAC) is mandatory.

Common Mistakes

Hardcoding Assumptions: Building the database schema under the assumption that "One Order belongs to One Vendor." When the business pivots to a marketplace model, the entire database has to be rewritten because a user can buy items from three different vendors in a single checkout.
Using B2C Tools for B2B Problems: Trying to force a B2B quoting process into a platform like standard Shopify, which requires writing messy hacks to bypass the credit card checkout.

Tradeoffs and Alternatives

Off-the-shelf vs. Custom: Shopify and BigCommerce are world-class for B2C. However, if your business model involves highly complex B2B workflows or multi-vendor payouts, trying to customize a SaaS platform often becomes harder than building custom microservices.
Merchant of Record (MoR): In a marketplace, do you take the legal responsibility for the sale (MoR), or do you just facilitate the payment? Taking MoR simplifies the user experience but vastly increases your legal and tax liabilities.

Interview Questions

A client wants to build a marketplace like Etsy. How would you design the database schema to handle an order that contains items from three different sellers?
How would you design a pricing API for a B2B company where every client has a different negotiated discount on every product?
Explain the architectural difference between a checkout flow that uses credit cards versus one that uses Net-30 invoicing.

Hands-On Exercise

Look at a popular app like Uber Eats or Airbnb. Map out the flow of money.

Who pays?
Who gets paid?
When is the money held in escrow?
What is the platform's commission? Sketch a basic database schema showing how you would track the Commission and Vendor_Payout for a single transaction.

Key Takeaways

Software architecture follows the money. You cannot design a system until you know exactly how the business charges its customers.
B2C systems prioritize speed, conversion rates, and simple pricing.
B2B systems prioritize workflows, approvals, complex pricing tiers, and invoicing.
Marketplaces introduce extreme complexity via multi-tenant data isolation and multi-party payment splitting.