Online Store Development

An online store is not "a site with a cart." It's a system for managing products, inventory, orders, payments, delivery, returns, and customer communication. Each of these blocks has non-trivial implementation, and most e-commerce problems arise at the intersection of these systems.

Catalog Performance: Where Everything Breaks

The most common technical problem in e-commerce — catalog performance degradation as SKU grows. Category page works well at 500 products and starts lagging at 10,000. Causes are almost always the same.

N+1 on attributes. Loading product list — 50 items. For each you need category, main image, price with discount, warehouse availability, rating. Without proper eager loading, that's 250+ queries per page. In Laravel solved via with(['category', 'mainImage', 'currentPrice', 'stockStatus']) and withAvg('reviews', 'rating'). But add personal prices (b2b) or regional warehouse balances — and one with() doesn't save. Need Query Object or dedicated ReadModel.

Faceted filtering without indexes. Filter by color + size + brand + price range on 500K record table without composite indexes — seq scan on every request. PostgreSQL with proper indexes holds faceted filtering up to several million products. For larger catalogs — Elasticsearch or OpenSearch with aggregations: they count products per filter (facet counts) much faster.

Pagination via OFFSET. LIMIT 50 OFFSET 10000 on large table — bad idea: PostgreSQL still reads first 10,050 rows. Keyset pagination (cursor-based) via WHERE id > $last_id ORDER BY id LIMIT 50 works in constant time regardless of page.

Concrete case: building materials catalog, 180,000 SKU, faceted filtering by 12 attributes. After switching from OFFSET pagination to cursor-based and adding partial index by (category_id, is_active, price) — catalog page response time dropped from 4.2s to 280ms.

Cart and Checkout

Checkout is where money either reaches the account or doesn't. Technical problems here are expensive.

Race condition during product reservation. Two buyers simultaneously add last item to cart and both press "Pay." Without pessimistic locking or atomic UPDATE with balance check — both orders go through, inventory goes negative. In PostgreSQL:

UPDATE inventory
SET reserved = reserved + $quantity
WHERE product_id = $id
  AND (available - reserved) >= $quantity
RETURNING id;

If RETURNING returned 0 rows — no product, show error before charging.

Idempotency of payment webhooks. payment.succeeded from Stripe or YuKassa can arrive twice — network issues, retry logic on payment gateway side. Without checking WHERE NOT EXISTS (SELECT 1 FROM processed_events WHERE event_id = $id) — duplicate order or double charge.

Multi-step checkout. Address → delivery → payment → confirmation vs single-page checkout. Research shows single-page with progress indicator converts better on mobile. State between steps — either localStorage + server-side session or completely server-side with intermediate save.

Integrations: 1С, Warehouse, Delivery

1С — separate chapter. Three common integration methods:

1. CommerceML via HTTP — 1С exports XML by schedule, site imports. Works for small catalogs, has sync delay.
2. REST API / OData from 1С — bidirectional real-time sync. Requires 1С setup, fussy about configuration versions.
3. Intermediate bus (RabbitMQ / Kafka) — 1С publishes events, site subscribes. Most reliable approach for high-load systems, but most expensive to develop.

Typical CommerceML pain: 200MB export file with full catalog every 30 minutes. Parsing blocks queue, import takes 10–15 minutes, site has old prices meanwhile. Solution — incremental export (changes only) and background processing via Laravel Queue with multiple workers.

Delivery services — SDEK, Boxberry, Russian Post, DHL: all provide REST API for cost calculation and shipment creation. Aggregators (Shiptor, Shipnow) allow working with multiple services through single API.

Payment Gateways

For each gateway, webhook signature verification is mandatory — without it anyone can send fake payment.succeeded.

CMS vs Custom Development

WooCommerce — justified for stores up to ~5,000 SKU with standard business logic. Quick start, huge plugin ecosystem. Problems start with non-standard pricing rules, complex product variants, or load of 10,000+ orders per month.

OpenCart, Prestashop — similar story. Good for start, limited on growth.

Custom Laravel development — for:

• Non-standard business logic (subscriptions, rentals, b2b price lists, configurator)
• High performance requirements
• Complex integrations (multiple warehouses, ERP, marketplaces)
• Unique checkout UX

SEO for E-commerce

Canonical and duplication. Faceted filtering generates thousands of URLs (?color=red&size=M&sort=price). Without canonical or noindex on filtered pages — crawl budget spent on duplicates, main pages indexed worse.

Structured data. Product schema with offers, aggregateRating, availability — rich snippets in search: rating stars, price, availability. Affects CTR.

Core Web Vitals on product pages. Product hero image is LCP element. fetchpriority="high" on first image, correct srcset with WebP, width and height attributes to prevent CLS.

Timeline Guidelines

Cost calculated after requirements analysis: number of integrations, pricing complexity, catalog volume, and UX uniqueness — main factors.

Checklist Before Launch

• Race condition on last product payment — covered by test
• Payment webhook idempotency
• Rate limiting on cart and checkout endpoints
• Canonicals on filtered catalog pages
• Receipt fiscalization (FZ-54 for RF or equivalent)
• Checkout stress test under load (k6 or Locust)
• Error monitoring (Sentry) and alerts on payment errors
• Database backup with verified restore process