The Fundamental Theory: Product Inventory Archetypes

Every physical product in the world falls into one of these tracking archetypes. This isn't a Khoji Nepal thing — this is universal retail/inventory theory:

1. Serialized Products (Individual Identity)

Each unit is unique and tracked individually.

Examples: Laptops, phones, motorcycles, gold jewelry
Stock tracking: By serial number. You know which specific iPhone was sold to whom.
Why: Warranty claims, theft tracking, returns, resale value.
Stock count: Exact integer (you have 3 MacBooks, not "approximately 3")

2. Batch/Lot Tracked Products (Group Identity)

Individual units are identical, but which batch they came from matters.

Examples: Medicines, dairy products, packaged food with expiry dates
Stock tracking: By batch. Batch #A2045 has 200 units, expires Dec 2026.
Why: Expiry management, recalls (if batch #B3001 is contaminated, pull only that batch).
Stock count: Quantity per batch, FIFO (First In, First Out) rotation.

3. Counted/Generic Products (No Identity)

Individual units are completely interchangeable. Nobody cares which one.

Examples: Noodle packets, biscuits, pens, screws, socks
Stock tracking: Just a number. "We have 450 packets of Wai Wai."
Why: No customer cares which specific packet they got.
Stock count: Simple integer, decremented on sale.
Your observation is correct: Nobody opens a carton to scan individual packets. You receive 1 carton = +48 units.

4. Weighed/Measured Products (Continuous Quantity)

Sold by weight, volume, or length — not by "unit."

Examples: Fruits, vegetables, meat, rice, fabric, fuel
Stock tracking: By kilogram/liter/meter. "We have 25kg of apples."
Why: You can't sell "1 apple" consistently — you sell "1.2 kg of apples."
Stock count: Decimal (25.5 kg), subject to shrinkage (evaporation, drying, spoilage).
Key complexity: The price is per-unit-of-measure (Rs 180/kg), but the sale amount depends on what the customer actually takes.

5. Variant Products (Attribute Combinations)

Same product, but multiple variations that each have their own stock.

Examples: T-shirts (size × color = 15 SKUs), shoes (size), phone cases (model + color)
Stock tracking: Per-variant. "Blue T-shirt Medium: 12 units, Red T-shirt Large: 0 units."
Why: A customer wanting a Medium Blue shirt doesn't care that you have 50 Large Reds.

6. Prepared/Made-to-Order Products (Ingredient-based)

The "product" doesn't exist in inventory — its ingredients do.

Examples: Restaurant food, bakery items, custom cakes, juice bars
Stock tracking: You don't track "how many momo plates" you have. You track flour (kg), meat (kg), spices (grams). When an order comes in, ingredients are consumed.
Why: A plate of momo is assembled on demand, not pre-stored.
Key complexity: Recipe/BOM (Bill of Materials) management.

7. Service Products (No Physical Inventory)

Nothing physical is tracked.

Examples: Haircuts, tailoring, tutoring, plumbing
Stock tracking: None. Just availability/scheduling.

Your Key Question: Separate Microservices per Type?

No. Absolutely not. Here's why:

A single vendor might sell multiple types simultaneously. A grocery store sells:

Counted items (noodle packets) — Archetype 3
Weighed items (rice, dal) — Archetype 4
Batch-tracked items (dairy, medicines) — Archetype 2

If you create separate microservices per archetype, that grocery store's inventory is fragmented across 3 services. Orders, reports, and dashboards become nightmares.

The Right Approach: Single Product Model with a Type Field

Product
├── type: "serialized" | "batch" | "counted" | "weighed" | "variant" | "prepared" | "service"
├── name, description, images, price...
├── unit_of_measure: "piece" | "kg" | "gram" | "liter" | "meter"
├── track_inventory: boolean
└── type-specific data (polymorphic)

The type field determines:

What fields appear in the vendor's dashboard (serial number field? expiry date? weight?)
How stock is decremented (subtract 1? subtract 0.75 kg? consume recipe ingredients?)
What the "Add Stock" form looks like (enter quantity? scan serial numbers? enter batch + expiry?)

This is how Shopify, Odoo, and SAP all handle it — one product model, behavior driven by type.

How This Maps to Khoji Nepal

For your marketplace, vendors don't need to understand any of this complexity. When they onboard:

They pick their store category (Grocery, Electronics, Restaurant, etc.)
The system knows which product archetypes that category uses
The "Add Product" form dynamically adapts

Store Type	Default Archetypes Available
Grocery / किराना	Counted, Weighed, Batch
Electronics	Serialized, Variant, Counted
Restaurant / Fast Food	Prepared (recipe-based)
Clothing / Fashion	Variant
Farm / Fresh Produce	Weighed, Batch
Services (Salon, Repair)	Service

The vendor never sees the word "archetype" — they just see a clean form that asks the right questions for their type of product.

What This Means for the Database

You don't need 7 different tables. You need something like:

products (id, vendor_id, name, type, unit_of_measure, price, ...)
  
product_variants (id, product_id, attributes_json, sku, price_override)
  → Only for type="variant"

stock_entries (id, product_id, variant_id?, quantity, batch_number?, expiry_date?, serial_number?)
  → The universal stock ledger
  → batch_number is NULL for non-batch items
  → serial_number is NULL for non-serialized items

recipes (id, product_id, ingredient_product_id, quantity_needed)
  → Only for type="prepared"

This is a single, clean relational model — not microservices.

Summary

Your Concern	Answer
"Fruits and laptops need different tracking"	Yes — solved by `product.type` field, not separate services
"Nobody tracks individual noodle packets"	Correct — that's the "counted" archetype. Just a number.
"Grocery is completely different"	It uses multiple archetypes (counted + weighed + batch) in one store
"Separate microservices?"	No. One product service, type-driven behavior
"What's the theory called?"	Inventory Tracking Archetypes / Product Type System

Want me to dive deeper into any specific archetype, or shall we start designing the actual database schema and Laravel models for this product type system?