3T Store
A marketplace where many sellers sell the same product and the customer sees one honest price — live at my3tstore.com

Live at my3tstore.com. Real sellers, real products, real orders — this is the store I run, not a demo.
What it is
A marketplace where many sellers sell the same product and the customer only ever sees one price.
It does two things at once. It runs a multi-seller shop, where each seller sets their own price, stock, shipping cost and warranty. And it does live price comparison: the cheapest listing that is in stock and still active automatically wins the product slot, and every product carries a 30-day price chart.
What it does
- The cheapest active listing wins the product slot. If two sellers tie on price, an official seller keeps it. The comparison uses price plus shipping, so it is against the number the customer actually pays.
- Checkout cannot oversell. If two people reach the last item at the same moment, one of them is told it is gone. Stock can never go negative — not because I check twice, but because the database only accepts the decrement if enough stock is there.
- One order per seller. A basket with three sellers produces three orders, each with its own payment link, because each seller ships and gets paid separately.
- Double-tapping Pay cannot charge twice. Every checkout takes an idempotency key, so a repeated request returns the original order instead of creating a new one.
- Phone login with a 6-digit code — typed with Persian or Latin digits, it is the same account. Codes expire in two minutes and can only be spent once.
- A product with no photo says “no photo.” No stock photos, no broken images, nothing pretending to be something it isn’t.
- Bilingual Persian/English, light and dark, working on a phone from the first version.
The numbers
| 22,400 | lines of code |
| 241 | source files |
| 12 | database tables |
| 3 | live services: web, API, search |
Why it’s worth a look
The interesting part is not the shopping cart — anyone can build that. It is the part that is easy to get wrong and hard to notice until it fails in front of a customer.
Money is stored as integers, not decimals, because Iranian rial amounts are large enough that a float loses digits. The OTP code is generated with a cryptographically secure generator and consumed with an atomic Redis delete, so two simultaneous requests cannot both spend it. Rate limiting lives inside a Lua script in Redis, because a read-then-write in application code is not atomic and a burst of parallel requests will slip through it.
And the deploy is not hopeful: the database, the cache and the search engine all have memory ceilings and health checks, so when the machine runs short of memory it fails in a controlled way instead of taking the site down with it.

