Quick Summary: Mapping multiple products to a single barcode is a database anti-pattern that destroys inventory accuracy; here is how to architect around the “same price” dilemma without breaking your backend logic.

One Barcode, Many Products: Architecting Around the “Same Price” Dilemma

I still have nightmares about a migration I led back in 2018 for a discount retailer. We were moving them from a legacy on-prem monolith to a microservices architecture on AWS. Two days before Black Friday, the chaotic “Anything for $5” bin became the bane of my existence. The client wanted every item in that bin—regardless of what it actually was—to scan with the exact same barcode to speed up checkout lines.

The result? Our inventory-service pods started crash-looping. Why? Because the system was trying to decrement stock for a “Generic Item” that didn’t physically exist, while thousands of actual distinct units were walking out the door unaccounted for. We spent Thanksgiving eating cold pizza and manually reconciling database rows. Here is why this happens and how to fix it before your prod-db-01 melts down.

The Root Cause: Speed vs. Granularity

The core tension here is between the Point of Sale (POS) speed and Warehouse Management System (WMS) accuracy. The business (Sales) wants the cashier to scan a code and hear a beep immediately. The backend (DevOps/Data) needs to know exactly which SKU left the building to trigger re-ordering workflows.

If you map 50 different items to one barcode, you are effectively performing a lossy compression on your sales data. You are stripping away the unique identifier (the SKU) and retaining only the attribute (the Price). From an architecture standpoint, this is a schema violation.

Pro Tip: Never let the physical label dictate your database schema. The barcode is just an input string; your logic layer should determine how that string resolves to an inventory object.

The Solutions

1. The Quick Fix: The “Dump” SKU (The ‘Bodega’ Method)

This is the “I need this working by 5 PM” solution. You create a single, non-inventory SKU in your database specifically for this price point.

How it works: You print one barcode representing “Generic $10 Item”. You slap it on the shelf, not the items. When scanned, it hits the `sales` table, but you explicitly disable inventory decrementing for this UUID.

-- The Hacky SQL Approach
INSERT INTO products (sku, name, price, track_inventory)
VALUES ('GEN-10-USD', 'Generic $10 Item', 10.00, false);

-- Result:
-- Cashier scans -> Transaction flows -> Inventory count remains null.

The Catch: Your analytics will be trash. You won’t know if you sold 100 red mugs or 100 blue hats. You only know you made $1,000. Use this only if inventory tracking for these specific items is irrelevant (e.g., clearance items you never intend to restock).

2. The Permanent Fix: Parent/Child Aliasing

This is the architecturally sound way to handle this. You treat the barcode as a “lookup key” rather than a primary key. In your database, you create a many-to-many relationship table between barcodes and product_variants.

When the barcode is scanned, the API doesn’t immediately add an item to the cart. Instead, it queries the relationship. If it finds multiple active SKUs tied to that barcode, it returns a 409 Conflict (or a custom 300 code) with a payload of options.

// Response from GET /api/v1/scan/{barcode}
{
  "status": "ambiguous",
  "message": "Multiple products found for this price point",
  "candidates": [
    { "sku": "MUG-RED", "name": "Red Mug", "price": 5.00 },
    { "sku": "HAT-BLU", "name": "Blue Hat", "price": 5.00 }
  ]
}

The frontend UI then prompts the cashier to tap the correct item. It slows down the line by 2 seconds, but your inventory data remains pristine.

3. The ‘Nuclear’ Option: The Vendor Override

Sometimes the software limits you, or the legacy code is spaghetti that no one wants to touch. The nuclear option is ignoring the manufacturer’s barcode entirely.

I call this “Nuclear” because it involves hardware and labor. You deploy a fleet of zebra printers and cover the manufacturer UPCs with your own internal UUID stickers.

We did this for a client dealing with imported goods where three different vendors used the same EAN code (don’t ask me how, international standards are merely suggestions in some factories). We simply generated our own hash, printed it, and covered the original.

If you are building the backend, Solution #2 is your job security. If you are just trying to survive Black Friday, Solution #1 will keep the servers running, just make sure you warn the CFO that their Q4 inventory report is going to be vague.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions