Ilnur Umirbayev

Problem

Every company in Uzbekistan that wants to accept payments integrates each provider separately: different auth schemes, different webhook formats, different error semantics. Teams spend weeks per provider and re-implement the same fragile logic in every project.

Architecture

  your app
     │  one consistent API surface
     ▼
┌──────────────────────────────────────────────┐
│                 uz-pay-sdk                   │
│   payments · webhooks · logging · analytics  │
├──────────────────────────────────────────────┤
│                driver registry               │
└───┬───────┬─────────┬─────────┬─────────┬────┘
    ▼       ▼         ▼         ▼         ▼
  Payme   Click    UzCard     Humo     Apelsin
    │       │         │         │         │
    └───────┴────┬────┴─────────┴─────────┘
                 ▼
    normalised webhook + idempotent handler
                 ▼
       Redis  ·  Winston (rotating logs)

Key technical decisions

• Driver / adapter pattern — each provider is an isolated driver behind one interface, so a new provider is added without touching consumer code.
• Normalised webhook layer with signature verification and idempotent handling, preventing duplicate charge processing on provider retries.
• Redis-backed caching and analytics for transaction lookups and provider health.
• Winston structured logging with rotation so production payment failures stay traceable.
• Full Swagger / OpenAPI documentation plus Jest tests over the core payment flows.
• Companion React Native SDK (@uz-pay/react-native-sdk) for in-app checkout.

Result

Problem

A growing marketplace needed to import and synchronise hundreds of thousands of supplier products without blocking the API, and to keep catalog search fast as the dataset multiplied.

Architecture

 Taobao / supplier APIs
        │
        ▼
 ┌─────────────┐   publish    ┌──────────────┐   consume   ┌──────────────┐
 │ import svc  │ ───────────▶ │  RabbitMQ    │ ──────────▶ │ worker pool  │
 └─────────────┘  topic exch. │  DLQ + retry │             │ normalise    │
                              └──────────────┘             │ media, price │
                                                           └──────┬───────┘
   catalog / search svc ◀── Redis cache ◀── PostgreSQL ◀──────────┘
          (300K+ SKU, composite indexes)

What I did

• Built microservices for product import, synchronisation, search and catalog operations.
• Integrated the Taobao API with automatic job processing and a queue-based pipeline, replacing manual data entry with unattended imports.
• Designed RabbitMQ event pipelines with retry and dead-letter strategies so one failing supplier never blocks the rest of the catalog.
• Designed and tuned PostgreSQL schemas and indexes for a 300K+ product catalog, keeping filter and category queries fast under load.
• Containerised all services with Docker and standardised CI/CD, improving deployment reliability and release cadence.
• Added monitoring, structured logging and error tracking, cutting time-to-detect on production faults.

Problem

Retail staff scan RFID tags in warehouses with unreliable connectivity. The backend had to ingest thousands of tag reads per request, survive offline periods without creating duplicate stock records, and stay auditable for compliance.

What I built

• Mass EPC processing pipeline handling 2,000+ tag events per request with batched writes and deduplication.
• Offline / online scan sessions with deduplication and idempotent replay, so scans recorded without network reconcile cleanly on reconnect.
• Zonal inventory logic across store floor, stockroom and reserve, giving operations real-time stock accuracy instead of manual reconciliation.
• Full audit logging and activity tracking over inventory mutations for compliance and dispute resolution.
• RBAC-secured REST API and admin-panel backend, documented in Swagger for parallel mobile and web delivery.
• Two-way ERP synchronisation via CSV, Excel and REST adapters, automating a previously manual data exchange.

What I built

• A 19-module executive platform covering production plan-vs-fact, energy, sales, finance, HR, ESG, fleet and site cameras for a metallurgical combine operating across seven sites.
• An integration layer normalising five external systems — Wialon GPS telematics, 1C:ZUP HR, Fusion Solar, an IP-camera platform and HET — each with live health, latency and error-rate monitoring so a broken upstream is visible in seconds rather than days.
• Real-time fleet monitoring for 80 vehicles over WebSocket, with auto-reconnect and REST polling fallback so the operations view survives network failures.
• Energy analytics across 20+ facilities aggregating electricity, gas and solar consumption into month-over-month and year-over-year comparisons.
• Redis caching and composite PostgreSQL indexes that reduced average API response time by 40–60% across the platform.