Rubick.ai (formerly Text Mercato)ProductionMLOps Engineer → Tech Lead · ML platform & MLOps · Production on AzureRubick.ai
Turning in-house ML into a cataloging platform 70+ specialists run on.
Rubick.ai turns raw seller product information into enriched, marketplace-ready catalog data for Myntra, Flipkart, Nykaa and Amazon. I built the infrastructure that took its fashion-cataloging ML from experiments to reliable production services, and the platform and APIs through which cataloging teams and clients used them.
- Role
- MLOps Engineer → Tech Lead
- Timeline
- Apr 2021 — Jul 2023
- Company
- Text Mercato → Cataloging.ai → Rubick.ai
- Cloud
- Microsoft Azure · Kubernetes
70+
Cataloging specialists
Daily users of the platform
1K+
Concurrent requests
Served by ML services on Kubernetes
~10K
Fashion data points
Collected for model training
4
Marketplaces
Myntra, Flipkart, Nykaa, Amazon
3
Environments
Dev, staging, prod via branch-aware CI/CD
2
Clients onboarded
Technical ownership end to end
01The problem
Models in notebooks don't publish catalogs.
Rubick had several in-house ML capabilities for fashion cataloging, but they lived as isolated experiments. Cataloging teams coordinated seller data across spreadsheets, tools, ML outputs and multiple workflows by hand, and nothing about the models was tracked, versioned or deployable in a repeatable way.
The job was the gap between a working model and a working product: experiment tracking, model serving, deployment automation, a secure entry point for APIs, and a single operational platform the cataloging team could actually run on.
A model is only one component of the system. The real engineering challenge is the infrastructure, workflows, deployment and product experience that make it dependable in production.
02My role
Every layer, explicitly.
No hand-waving about “contributed to”. These are the parts I designed, built and operated.
- MLOps
- Experiment management with MLflow, dataset preparation, model versioning and promotion.
- ML deployment
- Containerised inference services on Azure Kubernetes, scaled per workload for 1K+ concurrent requests.
- CI/CD
- Branch-aware GitHub to Kubernetes pipelines for the platform and ML services across dev, staging and prod.
- Platform engineering
- Secure API gateway from scratch with NestJS and Auth0, usage logging and access controls.
- Product engineering
- Led the in-house full-stack cataloging platform used by 70+ specialists.
- Backend
- Real-time price-intelligence services on NestJS, MongoDB and Elasticsearch.
- Client onboarding
- Led technical onboarding and post-onboarding support for two clients.
03What it does
Seller data in, marketplace-ready catalog out.
- 01Ingestseller product data
- 02Trigger MLattribute generation
- 03Reviewmachine-generated attributes
- 04Enrichproduct metadata
- 05Validatecatalog information
- 06Publishto marketplaces
Experiment management
MLflow for tracking experiments, training runs, parameters and hyperparameters, evaluation metrics, model versions and artifacts, so moving a model toward production was a structured comparison.
- MLflow
- experiment tracking
- model registry
Data collection
Crawling and data-collection workflows gathering ~10,000 fashion data points from public fashion sites, prepared and handed to ML engineers for training.
ML serving on Kubernetes
Containerised inference services on Azure Kubernetes with independent scaling per workload, environment configuration, application-to-model communication and production monitoring.
CI/CD automation
Git push → branch detection → CI pipeline → build → container image → Kubernetes deployment → target environment, for backend, frontend and ML services.
Cataloging platform
The in-house full-stack platform where 70+ specialists ingest seller data, trigger ML, review attributes, enrich, validate and prepare marketplace-ready listings.
- ingest
- trigger ML
- review
- enrich
- validate
- publish
API gateway
NestJS gateway with Auth0 authentication, authorisation, protected endpoints, request routing, usage logging, user-level activity tracking and service access controls.
Price intelligence
Real-time product price tracking and analysis: MongoDB for operational data, Elasticsearch for fast retrieval and analysis over large product datasets.
Azure operations
All production infrastructure and application deployments on Microsoft Azure, with deployment lifecycle management and troubleshooting.
Client onboarding
Requirements, workflow mapping, configuration, integration, troubleshooting and post-onboarding support for two clients, coordinating engineering and ML teams.
04Architecture
ML as services, behind one gateway, inside one platform.
A React cataloging platform and external clients reach the ML capabilities through a NestJS gateway. Each model runs as its own containerised service on Azure Kubernetes, with MLflow upstream and MongoDB and Elasticsearch alongside.
Client
Cataloging platform + client integrations
React full-stack app for 70+ specialists · external client APIs
API
NestJS API gateway and services
- Auth0 authentication & authorisation
- Request routing · protected endpoints
- Usage logging · user activity tracking
- Catalog ingestion · enrichment · validation
- ML trigger & review workflows
- Price tracking & analysis services
- Service access controls
- Environment configuration
Azure Kubernetes
containerised ML inference, per-workload scaling
MLflow
experiments, metrics, model versions
MongoDB
operational product & pricing data
Elasticsearch
fast retrieval over large product sets
GitHub CI/CD
branch-aware build & deploy
- Python
- MLflow
- Docker
- Kubernetes
- Microsoft Azure
- GitHub Actions
- NestJS
- Node.js
- Auth0
- MongoDB
- Elasticsearch
- React
- REST APIs
05Skills used
Everything the build touched, by layer.
ML & MLOps
- MLflow
- Experiment tracking
- Model versioning
- Model serving
- Dataset preparation
- Web crawling & data collection
Infrastructure & deployment
- Microsoft Azure
- Kubernetes
- Docker
- GitHub CI/CD
- Branch-aware pipelines
- Dev / staging / prod
- Production monitoring
Backend
- NestJS
- Node.js
- REST APIs
- Microservices
- MongoDB
- Elasticsearch
Platform engineering
- API gateway
- Auth0
- Authorisation
- Usage logging
- Access controls
- Scalable ML services
Product engineering
- Full-stack applications
- Catalog management
- Product enrichment
- Internal operations platforms
- Review workflows
Client & delivery
- Technical onboarding
- Workflow mapping
- Integration support
- Cross-team coordination
06Hard problems
Where the engineering actually lived.
- 01
From experiment to dependable service
Models existed as isolated experiments with no shared record of what worked. Introducing MLflow for runs, parameters, metrics and versions, then containerising the chosen models as Kubernetes services, turned promotion into a repeatable path rather than a hand-off.
- 02
Scaling inference to 1K+ concurrent requests
Each ML capability became its own containerised service so Kubernetes could scale them independently on demand. Environment configuration, application-to-model communication and monitoring were designed so one hot workload did not starve the rest.
- 03
Releasing three kinds of service without manual steps
Backend, frontend and ML services each needed their own build. Branch-aware CI/CD from GitHub to Kubernetes meant a push to a given branch built the image and deployed it to the matching environment, which cut manual deployment effort and made releases consistent.
- 04
Replacing spreadsheets for a 70-person team
The cataloging process spanned ingestion, ML triggers, attribute review, enrichment, validation and publication. Bringing it into one platform wired to the ML services, across backend architecture and user-facing workflows, made it the team's core daily tool.
- 05
One secure front door for ML
Internal and external consumers needed controlled access to backend and ML capabilities. A NestJS gateway built from scratch with Auth0 handled authentication, authorisation, routing and usage logging, giving visibility into how every API was consumed.
07Engineering decisions
Why it is built this way.
Why introduce MLflow before touching deployment?
Without tracked runs, parameters, metrics and artifacts there was no defensible way to say which model should go to production. MLflow gave ML engineers one place to compare experiments and register versions, which made the later promotion to a serving container a choice backed by numbers rather than memory.
Why Kubernetes on Azure for inference instead of one shared model server?
Different cataloging capabilities had very different load profiles. Containerising each model as its own service let us scale the busy ones independently, roll them out separately and keep a failing model from taking the others down. Azure was where the rest of the platform already lived.
Why branch-aware CI/CD across three services?
Backend, frontend and ML services shipped at different rhythms. Mapping branches to environments meant a push built a container image and deployed it to dev, staging or production on its own, so releases stopped depending on whoever remembered the manual steps.
Why a gateway with Auth0 instead of auth in every service?
Internal apps, cataloging workflows and external clients all needed access to the same ML capabilities. One NestJS gateway handling Auth0 authentication, authorisation, routing and usage logging kept the services simple and gave us per-user visibility into how APIs were consumed, which paid off in debugging and operational analysis.
Why MongoDB plus Elasticsearch for price intelligence?
Operational product and pricing records changed constantly and fit a document store. Analysis and search across large product sets needed an inverted index. Splitting write-heavy operational data from read-heavy retrieval kept both fast without forcing one store to do the other's job.
Why build an internal platform rather than wire up existing tools?
The team's workflow spanned ingestion, triggering ML, reviewing generated attributes, enrichment, validation and publication. Spreadsheets and point tools could not carry state across those steps. A single platform connected directly to the ML services became the core tool for 70+ people.
08What I'd tell another builder
A model is one component.
The infrastructure, workflows, deployment process and observability around it are what make it useful and dependable in production.
Own the whole lifecycle.
Data → experimentation → deployment → APIs → product → users → clients. Working across all of it is what shaped how I approach AI engineering today.
Automate the release before it hurts.
Branch-aware CI/CD across backend, frontend and ML removed the most error-prone manual work and made every environment predictable.
09Ownership
ML experimentation to model deployment to APIs to product workflows to cloud infrastructure to client onboarding: I owned the chain.
- MLflow experimentation
- Dataset collection
- Kubernetes model deployment
- CI/CD pipelines
- API gateway
- Cataloging platform
- Price intelligence backend
- Azure operations
- Client onboarding
Contribution
- MLOps & experiment management
- ML model deployment
- CI/CD automation
- API gateway & security
- Full-stack cataloging platform
- Price intelligence backend
- Azure operations
- Client onboarding
Built at Rubick.ai (formerly Text Mercato)
Want this kind of ownership on your team?