Design a reseller social-commerce app (Meesho)

With an average order of about ₹300 and a take rate close to zero commission, the platform earns very little per order, so infrastructure cost per order is a design constraint, not an afterthought. Images are the biggest cost: a user scrolls 100-300 product cards a day and every card is a picture. Generate variants once at upload (160, 320, 640 px widths) in WebP and AVIF, pick the variant on the client from screen width and network type, and target 15-30 KB per card instead of 150 KB. Use immutable URLs with a content hash so the CDN and the phone can cache for a year. Lazy-load below the fold and prefetch only the next screen. Deduplicate supplier images with a perceptual hash because many suppliers upload the same photo. Keep the API payload small too: send product IDs plus a compact card object, not the full product. Measuring this gives a strong answer: if 30M users load 200 cards a day, cutting 10 KB per card saves 60 TB of egress a day. The same thinking applies to compute: pre-compute feed candidates in batch, cache aggressively, and run ranking on cheap CPU models rather than calling heavy models per request.

The reseller earns the margin only when the buyer keeps the product. So the ledger must model money that moves through states: pending when the order is placed, confirmed after delivery plus the return window, reversed on return or RTO, and paid when the payout runs. Model it as an append-only ledger of entries (accrue, reverse, payout) rather than a balance column that you update. The balance is the sum of entries; a materialised balance can be cached but is always rebuildable. Every entry carries the order_id and a type, with a unique constraint on (order_id, type) so a replayed Kafka event cannot accrue twice; this is how you get effectively-once from at-least-once delivery. Payouts run as a batch: select confirmed, unpaid entries, create one payout per reseller with an idempotency key, call the bank payout API, and write the payout entry only when the bank confirms. A daily reconciliation job compares the ledger with bank payout reports and with order states, and raises alerts for any mismatch. Store money as integer paise, never floats.

Most orders in Tier-2/3 towns are cash on delivery, and a large share of COD orders are refused at the door or the address is not found. Each RTO costs forward plus reverse shipping, often more than the platform earned. So decide at checkout whether to allow COD. The order service calls a risk service with features: pincode RTO history, address completeness score (does it have a landmark, a house number), the buyer's past refusals, order value, time of day and whether the order came through a reseller with a good history. The model returns a score in a few milliseconds from an in-memory feature store; above a threshold COD is hidden and prepaid UPI is offered, perhaps with a small discount. Also confirm high-risk orders with an automated IVR or WhatsApp message before shipping. The decision must fail open in a controlled way: if the risk service times out (budget 50 ms), fall back to a simple rule based on pincode, not to blocking all orders.

Many users do not search; they scroll. The feed is a two-stage system. Offline, a batch job (Spark) builds candidates per user from category affinity, regional popularity, price band and what similar users shared or bought, and stores the top few hundred product IDs in Redis. Online, the feed service takes the next page of candidates, removes out-of-stock and already-seen items, and ranks them with a light model that uses fresh signals from the last session (clicked categories, price range). Cold-start users get regional bestsellers in their language. Product titles and attributes are translated or transliterated so a user in Lucknow and one in Coimbatore both see readable text. Keep the feed cursor stateless (encode the offset and a seed) so any server can serve the next page.

The share link carries a margin, but the client never sends the final price. The order service recomputes supplier price + margin + shipping on every order. This costs one extra lookup but closes an easy fraud path where a modified client or link changes the price. If the supplier price changed since the share, show the new total before confirmation.

Orders and money need transactions, unique constraints for idempotency and easy reconciliation queries, so Postgres sharded by buyer_id (or Citus/Vitess) fits. Shares, events and feed candidates are simple key lookups at high volume, so a key-value store and Redis are cheaper there. Using one database for everything either wastes money or loses correctness.

Paying immediately feels good for resellers but creates clawback debt when orders are returned, and some resellers disappear. Paying weekly after delivery + return window is safer. A middle path is showing 'pending' earnings instantly and offering an early payout of part of it to trusted resellers.

Many buyers do not have the app. A server-rendered web page under 100 KB, cached at the CDN, converts better than forcing an install on low storage phones. The app is still the main surface for repeat users.

During a sale a handful of products get most views and orders. Product pages are served from cache (Redis + CDN for static parts). Stock for hot SKUs becomes a hot row; use a conditional decrement in Redis with periodic sync to Postgres, or split stock into a few buckets, and reconcile asynchronously.

Bulk uploads of millions of images can swamp workers. Put image jobs on a queue with per-supplier fairness, autoscale workers on queue depth, and show products only after the 320 px variant is ready.

Queries come in Hinglish and regional scripts with spelling errors. Use transliteration, synonym dictionaries and per-language analyzers in Elasticsearch; at 10x, split indexes by category and add a query-result cache for popular queries.

Shipment creation is asynchronous from a Kafka consumer, so orders still get placed. The consumer retries with backoff, then routes to a second partner serving that pincode. Orders waiting too long raise alerts to operations.

The app sends an Idempotency-Key per checkout attempt. A retry with the same key hits the unique constraint and returns the original order, so the buyer is not charged or shipped twice.

Unique (order_id, type) on ledger entries makes replay harmless. Daily reconciliation catches anything missed, for example an order delivered but no confirm entry.