E-Commerce Infrastructure
Storefronts are the easy part. Marketplaces live or die in the plumbing — catalog services that stop scaling, carts that drop orders, pricing that breaks at the first border. I build that plumbing, and I've kept it running in production.
When you'd call me
- You're building a marketplace and there's no backend team — you need the architecture and the first production version, not a slide deck.
- Your current infrastructure worked at ten thousand products and is visibly straining at a million.
- You're expanding into cross-border sales, and pricing suddenly means currencies, VAT regimes and localized payment flows all at once.
- The cart-to-payment pipeline keeps shedding orders and nobody can point to the exact step where they vanish.
What I do
- Service architecture in Go — product, order, user, auth and shared common services, cut along the seams where the domain actually splits.
- A Redis caching layer designed around the catalog — including a category-tree cache strategy that holds up at 7 million products.
- RabbitMQ workers for everything that shouldn't block a request: stock syncs, exports, notification fan-out.
- Cross-border pricing — multi-currency, VAT handled per market, and a payment flow localized for each side of the border.
- Lifecycle messaging — push and e-mail journeys from welcome to abandoned cart; the last set was 28 templates in Turkish and Macedonian variants.
Two neighboring problems have their own pages: product discovery is covered under hybrid search & retrieval, and the physical side — packages, customs, the warehouse floor — under fulfillment & warehouse management.
Numbers, not adjectives
Stork is a cross-border marketplace between Türkiye and North Macedonia that I took from an empty repository to production: Go microservices for product, order, user and auth, Redis in front of a 7-million-product catalog, RabbitMQ workers for the async work, multi-currency pricing with cross-border VAT, and 28 lifecycle message templates in two languages. It sells real goods to real customers every day.
Field notes
Where we'd start
Discovery starts with an architecture audit: I read your services, your data model and your traffic, and you get a written scaling roadmap — what breaks next, in which order, and what fixing each stage costs. If the honest answer is that your stack is fine and you need two indexes and a cache, the document says that.