# Myntra Stories of code. - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## From Products to Inspiration: Inside the Engine of Occasion-based outfit visualiser DevFeed: [From Products to Inspiration: Inside the Engine of Occasion-based outfit visualiser]() Original publisher: [Read original article]() Author: Ankit Kumar Published: 2026-04-23T18:23:51Z Content type: article Language: en Sources: [Myntra]() Topics: [Data Science](), [Computer vision](), [Generative AI](), [JSON]() Tags: [ai](), [computer-vision](), [data-science](), [drapes](), [generative-ai](), [json](), [occasion-based-shopping](), [outfit-ideas](), [product](), [shopping]() ### AI overview This article describes how Myntra built its Looks occasion-based outfit visualiser. The feature combines fashion intelligence, data science, computer vision, generative AI, and JSON-based outfit rules to turn individual product images into coordinated outfit recommendations and visualisations. The supplied text details its style taxonomy and curation of over a million styles, but the article is truncated before the visualisation implementation is fully explained. ### Source excerpt Ankit Kumar | Oct 2025 - 6 min read The "Why": Moving Beyond the Grid Picture this: A white background. A shirt. Fabric details. Fit specs. A price tag. For decades, this has been the status quo of online shopping. It is clinical, clear, and -- let's be honest -- completely detached from real life. In this model, the customer does all the heavy lifting. "Where would I wear this?" they wonder. "Does this go with those beige chinos I bought last year?" They close their eyes. They imagine. They guess. Sometimes they buy; often, they bounce. Traditional Product Detail Page (PDP) recommendations tried to help by suggesting jeans to pair with shirts. But the truth is, they remained a list of ingredients, not a prepared meal. At Myntra, we decided to change that. We set out to build Looks, a feature designed to transport a static product into a lived experience -- a Friday night in Bangalore, a high-intensity gym in Gurgaon, or a quiet art gallery in Mumbai. This is the story of how we orchestrated Data Science, Computer Vision, and Generative AI to build a personal stylist that scales to millions. Phase 1: The Brain -- Orchestrating the Look Before we could visualize an outfit, we had to understand fashion. Not just as data points, but as a language. This required Fashion Intelligence: a system that knows what works, what doesn't, and why. Our Data Science team undertook a massive curation effort, analyzing over a million styles. They didn't just tag clothes; they mapped them to the "cascading tree of style." For every Primary Style (e.g., a Polo shirt), the engine identifies four critical layers: The Occasion: (Weekend Outing, Office Smart-Casual) Secondary Style: (The bottom wear) Tertiary Style: (Footwear) Tertiary (others) : (Accessories like watches or sunglasses) The Recipe in the Code The logic is powered by a JSON structure that acts as the "AI Stylist's" brain: JSON "29936239": [ { "Weekend outing": [ [ 29936239, // Primary: The Polo T-Shirt 33551732, // Secondary: B ## Revamping Myntra App Analytics persistence with KMP and SQLite DevFeed: [Revamping Myntra App Analytics persistence with KMP and SQLite]() Original publisher: [Read original article]() Author: Kartik Sharma Published: 2026-03-31T13:01:09Z Content type: article Language: en Sources: [Myntra]() Topics: [App](), [SQLite](), [Persistence](), [SDK](), [Databases](), [legacy](), [Error Handling]() Tags: [android](), [app](), [databases](), [error-handling](), [ios](), [kotlin-multiplatform](), [legacy](), [mobile-app-development](), [persistence](), [sdk](), [sqlite]() ### AI overview This engineering post describes Myntra's effort to re-architect the persistence layer of its app analytics SDK. It explains how a legacy Android pipeline using in-memory queues and SharedPreferences created performance and data-reliability bottlenecks as event volume grew, and introduces a SQLite-backed persistence engine intended to improve app stability and data integrity. ### Source excerpt Introduction In the dynamic landscape of e-commerce, data is the bedrock of decision-making, and app stability is the foundation of user experience. At Myntra, where millions of users engage with our platform daily, ensuring the reliability of both is paramount. This necessity drove us to re-architect a critical piece of our infrastructure: the persistence layer of the Myntra app's analytics SDK. This post details our journey of augmenting our legacy analytics SDK with a robust new persistence engine backed by SQLite[1], achieving significant gains in app stability and data integrity. Background: The Limits of the Legacy Pipeline For years, our legacy in-house analytics SDK was the workhorse for collecting user interaction data. However, as our app's event volume grew, the SDK's aging persistence and processing logic created significant bottlenecks that led to degraded app performance and compromised the reliability of analytics data our product teams depended on. On Android: The Legacy Pipeline and its Limits On Android, the legacy analytics pipeline followed a straightforward event processing model: Capture, Persist & Batch: Events generated by used actions were held in an in-memory queue and then serialized into a persistent queue backed by SharedPreferences[2]. Once a batch threshold was met (typically 10 events), the batch was dispatched to the server. Background Flushing: Periodic background jobs flushed unsent events and retried failed batches. Error Handling: Failed batches were pushed to a separate retry queue, with older events silently purged if the queue hit its cap. High level overview of legacy android pipeline At the time of the initial implementation, SharedPreferences was a pragmatic choice to prioritize velocity. The ecosystem for local databases on Android was still maturing, and raw SQLite often required significant boilerplate compared to the simplicity of a key-value store. However, SharedPreferences is architecturally limited for high-throughp ## Enhancing Myntra App performance: Transitioning from GIFs to Videos DevFeed: [Enhancing Myntra App performance: Transitioning from GIFs to Videos]() Original publisher: [Read original article]() Author: Kartik Sharma Published: 2025-08-30T07:00:01Z Content type: article Language: en Sources: [Myntra]() Topics: [App](), [image animation](), [Mobile](), [Playback](), [Android](), [iOS]() Tags: [android](), [app](), [gif](), [h-264](), [ios](), [mobile-app-performance](), [performance](), [videos]() ### AI overview Myntra describes transitioning animated content in its Android and iOS apps from GIFs to video formats. The article attributes the change to GIFs' high memory usage, lower visual quality, large file sizes, and resulting performance and loading concerns, while comparing alternatives including WebP, APNG, and H.264/HLS video. ### Source excerpt Introduction In the fast-paced world of e-commerce, every millisecond and every pixel counts. At Myntra, where visual content drives discovery and engagement, we embarked on a critical mission: to revolutionise how animations are delivered in our Android and iOS apps. This journey led us to transition from the ubiquitous GIF format to more efficient video formats, unlocking significant performance gains and a superior user experience. Background on GIFs The Graphics Interchange Format (GIF) has been a widely-used format for looping animations since its introduction in 1987. Its simplicity and broad compatibility made it a go-to choice in mobile apps. However, despite its ubiquity, GIFs come with several drawbacks that can negatively impact app performance and user experience. Challenges with GIFs in Myntra App At Myntra, we used GIFs extensively for animations in our home and brand page's widgets. Our existing Image components provided easy GIF playback. However, GIFs came with some serious drawbacks in native mobile environments: High Memory Usage: GIFs often lead to Out of Memory (OOM) errors, especially on low-end devices. Low Quality: Limited frame rates and poor bitmap quality degraded the visual experience. Large File Sizes: GIF assets were large, increasing network load and loading times. To mitigate these issues temporarily, we implemented several workarounds. These included optimising GIF assets and imposing restrictions on the file size of GIFs during the ingestion process. However, these were interim solutions and the move to an alternate was necessary for a more permanent and effective fix. Exploring Alternatives Before settling on a solution, we explored several alternatives to GIFs: WebP: This format offers better compression and quality than GIFs. It has broad web support and is native on Android, but is only supported natively on iOS versions 14 and above. APNG (Animated PNG): APNG provides excellent image quality and strong web browser support. Howe ## Size Recommendation System at Myntra DevFeed: [Size Recommendation System at Myntra]() Original publisher: [Read original article]() Author: Aayushi Das Published: 2025-01-30T06:25:43Z Content type: article Language: en Sources: [Myntra]() Topics: [Data Science](), [implementation](), [real-time](), [dashboards](), [Database]() Tags: [blog](), [dashboards](), [data-science](), [e-commerce](), [engineering](), [fit-and-size](), [implementation](), [models](), [online-shopping](), [performance](), [pipelines](), [real-time](), [recommendations](), [retail]() ### AI overview This article describes Myntra's Size Recommendation System for personalized clothing size and fit recommendations. It explains how the system uses users' past purchases and Try Size Finder inputs, provides real-time recommendations, monitors performance with dashboards, and refreshes models and vectors through offline pipelines. ### Source excerpt In recent years, online shopping has surged, revolutionizing how people purchase products and services. E-commerce's convenience has reshaped consumer behaviour and the retail landscape. Unlike traditional stores, online shoppers often face sizing challenges, leading to hesitancy and missed sales. Myntra has been a pioneer in addressing size and fit challenges in India, leading the way with innovative solutions that have significantly enhanced the shopping experience. Building on its leadership in this space, Myntra's latest initiatives take these solutions to the next level, offering even sharper and more effective recommendations. Solving this complex problem requires a combination of various features addressing size and fit issues. This blog details Myntra's approach to size and fit recommendations, including our solution, implementation, offline pipelines, online services, handling size recommendation leakages, A/B analysis and more, providing a comprehensive overview of our strategies and outcomes. What is the solution being used at Myntra? Personalized recommendations are generated using data science models, which rely on two main types of inputs - Past purchases of the user Size and fit inputs provided through the "Try Size Finder" questionnaire for users without purchase history Image 1: Recommendation based on past purchasesImage 2: Recommendation based on user inputsHow have we implemented this solution? We have implemented a Size Recommendation System (SRS) to personalize size and fit recommendations for Myntra users, enhancing their shopping experience. This end-to-end service provides real-time size recommendations based on user profiles, purchase history and inputs, ensuring a seamless and engaging buying process. System performance is monitored via dashboards with appropriate alerts. Offline pipelines The models tend to degrade over time due to drifts. To address this issue, we have established refresh cycles at suitable frequencies to maintain high c ## Configuring Azure Kubernetes Service Control Planes and Node Pools DevFeed: [Configuring Azure Kubernetes Service Control Planes and Node Pools]() Original publisher: [Read original article]() Author: Sumit Prasad Published: 2024-12-12T12:53:34Z Content type: tutorial Language: en Sources: [Myntra]() Topics: [Azure Kubernetes Service](), [Kubernetes](), [Azure](), [Containers](), [Orchestration](), [Scalability](), [Architecture & Design](), [DevOps]() Tags: [aks](), [aks-best-practices](), [aks-upgrade](), [architecture](), [azure](), [azure-kubernetes-service](), [best-practices](), [components](), [coredns-scaling](), [devops](), [getting-started](), [guide](), [ingress](), [kubernetes](), [performance-optimization](), [scalability]() ### AI overview This guide explains how to configure Azure Kubernetes Service (AKS) for performance and scalability. It describes the managed control plane, worker-node-based node pools, workload separation, and taints used to isolate system, ingress, platform, and application workloads. ### Source excerpt Introduction In this guide, we'll explore the intricacies of configuring Azure Kubernetes Service (AKS) for optimal performance and scalability. As a fully managed container orchestration service by Microsoft Azure, AKS simplifies deploying, managing, and scaling containerized applications using Kubernetes. Drawing from our extensive experience running AKS at scale, this blog aims to provide practical insights and solutions to common challenges faced by DevOps engineers, system administrators, and Kubernetes enthusiasts. We'll walk you through the AKS setup, offering step-by-step guidance, best practices, and tips from real-world scenarios. From fine-tuning the control plane to optimizing node pools, our goal is to equip you with the knowledge to leverage AKS in production environments fully. Join us as we delve into key considerations, navigate potential pitfalls, and share advanced configurations. Whether you're just getting started with AKS or looking to enhance your existing setup, this blog promises a comprehensive dive into Azure Kubernetes Service, informed by our hands-on experiences and lessons learned. AKS Architecture The AKS control plane, a managed service provided by Azure, oversees the management and orchestration of the Kubernetes cluster. It handles tasks such as scheduling, scaling, and monitoring the cluster. Node pools, or worker nodes, are the virtual machine scale sets that run the containers in the AKS cluster, executing workloads and running applications. Our AKS architecture, illustrated in the diagram below, includes multiple node pools, each dedicated to a specific purpose: System Node Pool: Hosts system-critical pods or add-on services managed by AKS. User Node Pools: Three user node pools are designated for: Platform components Ingress Application pods To ensure each node pool serves its intended purpose, we apply taints during their creation: The system node pool has a taint with the key-value pair CriticalAddonsOnly=true:NoSchedule. Th ## Fact Evaluation in Millions: Scalable Rule Executor Service DevFeed: [Fact Evaluation in Millions: Scalable Rule Executor Service]() Original publisher: [Read original article]() Author: Nikhil Anand Published: 2024-10-01T13:47:49Z Content type: article Language: en Sources: [Myntra]() Topics: [systems](), [Scalability](), [Requirements](), [Architecture & Design](), [implementation]() Tags: [availability](), [consistency](), [frequent-rule-updates](), [implementation](), [latency](), [performance](), [requirements](), [rule-engine](), [rules-in-millions](), [scalability](), [stateless](), [systems]() ### AI overview This engineering article describes Myntra's Rule Executor Service, designed to evaluate millions of facts against a similarly large set of rules for multiple tenants. It outlines requirements for scalability, reliability, availability, consistency, low-latency evaluation, dynamic rule management, immediate rule reflection, and fact assessment details. ### Source excerpt Overview The Rule Executor Service at Myntra stands out as a pivotal tool in the domain of rule engine. While, at a glance, one might wonder what sets it apart from the myriad of rule engines available today, the difference is profound. In Myntra ecosystem, supporting numerous pricing use cases necessitated building a capability that is engineered to handle vast volumes of rules, processing millions of facts against similar scale in terms of rules for multiple tenants with high reliability, performance, availability and consistency. In order for the system to be performant and use as a broker for all Myntra systems preference was given to scalability, and ability to persist and evaluate large large number of rules with low latency evaluation window. Functional & Non-Functional Requirements Let's first delve into the functional and non-functional requirements that necessitate the creation of the Rule Executor Service. Functional Requirements Dynamic Rule Management: The rule engine should be designed with adaptability as a core principle, enabling administrators or users to effortlessly update, introduce, or dynamically remove rules through the user interface as the landscape evolves. Immediate Rule Reflection: Following any changes to the rule set, the rule engine should ensure that all future fact evaluations reflect the latest rule standards with high degree of consistency. Once the creation, updating, or deletion of a rule has been confirmed as successful for the user, no subsequent fact evaluations should be conducted with the outdated rules from that timestamp onwards. This necessitates the updates to be immediately reflected in the knowledge base of the rule engine. Fact Assessment Details: Each evaluated fact should be supplemented with essential details, including the associated rule's ID, name, and description against which it was evaluated. In the absence of configured rules for the provided fact, enrich the fact by incorporating pertinent details regardin ## Future-Proof Your AKS Cluster with Strategic IP Address Planning DevFeed: [Future-Proof Your AKS Cluster with Strategic IP Address Planning]() Original publisher: [Read original article]() Author: Sumit Prasad Published: 2024-06-25T09:12:09Z Content type: tutorial Language: en Sources: [Myntra]() Topics: [Azure Kubernetes Service](), [Azure](), [Kubernetes](), [networking](), [configuration](), [Scalability]() Tags: [aks](), [azure](), [azure-kubernetes-service](), [cni](), [configuration](), [container-networking](), [ip-address-planning](), [kubernetes](), [kubernetes-scaling](), [load-balancer](), [networking](), [scalability]() ### AI overview This article explains IP address planning for Azure Kubernetes Service clusters using default Azure CNI networking. It compares static and dynamic IP allocation and describes how pod, node, and internal load balancer scaling affects subnet capacity and resource utilization. ### Source excerpt Scaling Kubernetes efficiently is an art that blends strategic planning with technical expertise. In Azure Kubernetes Service (AKS), mastering the allocation of IP addresses is crucial for ensuring seamless scalability and optimal performance. When configuring an AKS cluster with default Azure CNI networking, it's essential to address the nature of scaling Pods, Nodes, and internal LoadBalancer-type services. This blog delves into the intricate process of IP address planning, explicitly focusing on scaling Pods, Nodes, and Services in an AKS cluster. Discover how thoughtful IP management can prevent bottlenecks, optimize resource utilization, and pave the way for a robust production environment. Image Source: https://kubernetes.io/docs/images/kubernetes-cluster-network.svg We'll talk about two approaches to IP address planning in AKS: Static IP allocation and Dynamic IP allocation. Let us understand a bit about both, and then we will go deeper to understand each approach. Static IP Allocation: Suitable for predictable and stable environments where the maximum number of pods per node is known and does not change frequently. This approach can lead to IP wastage if the number of pods varies. Dynamic IP Allocation: Better for environments with varying workloads and dynamic scaling needs. It helps reduce IP wastage by allocating additional IPs only when necessary, but it requires careful subnet planning with a buffer to accommodate dynamic allocations. Static IP Allocation The default configuration in AKS uses static IP allocation based on the 'maximum number of pods per node' setting, counting all pods created from Deployments, Daemonsets, Statefulsets, or Jobs. The private subnet CIDR specified during node pool configuration assigns IP addresses to Pods, Nodes, and Load balancer type services for an internal network. It is essential to decide the "maximum pods per node" configuration and to have a dedicated subnet CIDR range before creating a node pool. AKS reserves th ## Building Myntra's Video Platform: Part 4 DevFeed: [Building Myntra's Video Platform: Part 4]() Original publisher: [Read original article]() Author: Shikhar Shrivastav Published: 2024-06-07T05:29:57Z Content type: article Language: en Sources: [Myntra]() Topics: [Streaming](), [real-time](), [Latency](), [Requirements]() Tags: [article](), [ecommerce](), [influencers](), [latency](), [livestream](), [real-time](), [requirements](), [series](), [social-commerce](), [streaming]() ### AI overview Part 4 of Myntra's Video Platform series examines the architecture of its livestreaming use case. It outlines platform requirements and compares prerecorded video livestreams with camera-feed livestreams, including their respective advantages and limitations. ### Source excerpt This article is the 4th one in the series 'Building Myntra's Video Platform'. In case you haven't read the first three parts, you may want to read the same for better context. Building Myntra's Video Platform: Part 1 Building Myntra's Video Platform: Part 2 Building Myntra's Video Platform: Part 3 In this article we will dwell a bit more on the architecture aspects. We use our Video Platform for Video On Demand (VOD) and Livestream use cases. The focus here will be the Livestream use case. Top Requirements Platform to transcode videos in HLS Adaptive Bitrate Streaming Near accurate color reproduction Support live commerce features Comments & other interactive elements to be added Support multiple concurrent livestreams Ability to support multiple hosts in the same livestream Glass to glass latency to be less than 15 seconds and ability to tune that further Ability to support lakhs of concurrent users and potentially millions in the future Livestreaming types In industry 2 different kinds of livestreams are popular Pre Recorded video as Livestream Camera feed as Livestream Pre Recorded video as Livestream Here a video is pre recorded and served as a livestream at the specific time. Pros: More control: You can edit the video beforehand to ensure everything is polished and exactly how you want it. No worries about technical glitches or unexpected moments during a live broadcast. Scheduling: Can be easily scheduled and broadcasted at the required time Repeatable: Can be streamed multiple times Cons: Lacks interaction: Viewers can't interact with the streamer in real time, which can make the experience less engaging. Feels less authentic: Viewers may notice content repeating across several livestreams Missing out on live engagement: You can't capitalize on the excitement and momentum that can come from a live stream. Camera feed as Livestream Here the host relays the camera feed as livestream for everyone 's consumption. Pros: Real-time: Shows events as they happen, crea ## Location-Based Fashion Recommendations at Myntra DevFeed: [Location-Based Fashion Recommendations at Myntra]() Original publisher: [Read original article]() Author: Siddhartha Devapujula Published: 2024-04-22T11:25:37Z Content type: tutorial Language: en Sources: [Myntra]() Topics: [recommendation systems](), [Machine learning](), [recommendations]() Tags: [artificial-intelligence](), [ecommerce](), [fashion](), [location-based](), [machine-learning](), [personalisation](), [recommendation-system](), [recommendation-systems](), [search]() ### AI overview Myntra explains how machine-learning recommendation systems can use location as user side information to improve personalized fashion recommendations, including for cold-start users. ### Source excerpt Authored By Rohit Gupta & Siddhartha Devapujula Introduction Millions of users visit Myntra daily to upgrade their wardrobes and millions of items are listed on the platform at any given time. Users neither have the time nor the capability to scroll through this vast list of items. Even after applying category and attribute filters, usually the number of items is still in thousands. Hence it becomes critical that the top search results for any user are both relevant and personalized. Just like search, many other recommendation widgets across the platform face the same challenges. Fashion Diversity -- Every Region has its own Fashion Showing each user the best styles for them from a catalog of million plus products is where machine learning based recommendation systems come into play. From search results on google to your netflix home screen, recommendation systems are working in the background to get you the best results. It is impossible to imagine modern age internet experience without these systems. The uber goal of these models is to take the user features and the vast list of items as input ,and generate a small personalized list of items for each user. For these systems to work, we mainly use the user's historical activity on the platform. In this blog we will see how using other kinds of user details can also enhance the quality of recommendations. In the next sections, we dive into the details of recommendation systems and related techniques. We explain the motivation for a location based recommendation system and how we built one at Myntra. Later we discuss a few use cases at Myntra, results and potential future work. Basics of recommendation systems This is a very simple read about recommendation systems by Google -- Recommendations: What and Why? | Machine Learning | Google for Developers. Readers can skip if they are already aware of this. Traditional recommendation models focus on using the user's historical interactions on the platform to learn. This wor ## Category Prediction for Search Query Understanding DevFeed: [Category Prediction for Search Query Understanding]() Original publisher: [Read original article]() Author: music and waves Published: 2024-04-21T12:40:48Z Content type: article Language: en Sources: [Myntra]() Topics: [Query (disambiguation)](), [Training AI Models](), [datasets](), [data]() Tags: [ai](), [classification](), [data](), [deep-learning](), [ecommerce](), [information-retrieval](), [model](), [neural](), [nlp](), [search](), [text-classification](), [train](), [training]() ### AI overview This article describes Myntra's multi-label product-category classification model for understanding ambiguous search queries. It covers preparing query-and-category training data and training a neural text classifier to predict relevant categories for live searches. ### Source excerpt Navigating through online shopping platforms can sometimes feel like finding your way through a maze. Take the search bar, for example. You type in "winter upper wear," hoping to find the perfect jacket or cozy sweatshirt. But here's the tricky part: the search engine has to decipher what you mean. Is it jackets you're after? Or maybe sweatshirts? Or both? It gets even more confusing when you consider the overlapping categories. Kurtas can be standalone articles or part of kurta sets. And loafers? They could belong to formal shoes or casual shoes and certainly not sports shoes. See the challenge? To tackle this, Myntra uses a multi-label search to product category classification model. It's like having an assistant that can understand possible intents from your search query. So when you type in something like "whey," the model knows you might be looking for protein or health supplements. But here's the catch: search queries can be short and vague, and they often use words that don't directly match category names. People might search using different terms or even regional variations. So, the model needs to be clever enough to map those words to the right categories internally. The goal is to capture all possible intents without cluttering your search results with irrelevant stuff. After all, nobody likes sifting through pages of irrelevant products. It's a delicate balance between covering all bases and keeping things tidy. Solution The solution has 2 major components. I. Data preparation We prepare ( search query : categories ) data points to be consumed in training by the neural classifier. Ex. ( ethnic wear : kurta, sarees ) II. Training a neural model We train a neural multi-label text classifier that consumes the prepared training data which is used to predicts categories for search queries live. I. Data Preparation We generate the supervised text classification training data in form of a search query and its product category(s) as its labels. This set is enrich