# Dream11 Engineering Here's a glimpse into life at Dream Sports. Learn more about our innovations, and practices across tech, culture and community that 'make sports better' for all. - 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. ## How Dream11 Built a Real-Time AI Sports Streaming Companion DevFeed: [How Dream11 Built a Real-Time AI Sports Streaming Companion]() Original publisher: [Read original article]() Author: Dream Blog Published: 2026-06-15T09:51:14Z Content type: tutorial Language: en Sources: [Dream11 Engineering]() Topics: [AI Agent](), [Streaming](), [Artificial Intelligence](), [real-time](), [voice ai](), [Sports]() Tags: [agent](), [ai](), [ai-agent](), [creators](), [cricket](), [latency](), [real-time](), [sports](), [streaming](), [tech](), [voice](), [voice-ai]() ### AI overview This developer article describes Dream11's AI Companion, a multilingual voice AI agent that joins live creator streams as a co-host. It explains that the system watches matches, reacts to events, interacts with creators and audiences, hosts trivia, and supports live cricket commentary with approximately two-second voice latency. ### Source excerpt Written by Narayan Sharma, Rajesh Mohanty, Dhruv Nigam, Chetna Meena and Palash TatteThe Moment That Sparked Everything Picture this: a live cricket stream. A boundary flies to the fence. The creator reacts; screaming, laughing, and enjoying the moment. The audience piles on in the chat. And in the corner of the screen, a street-smart monkey named Googly Bhai mutters: "Bhai kya cover drive mara Kohli ne, ball field pe aise glide kar rahi hai jaise garam parathe pe makkan!" The audience erupts. Not because it was scripted. Not because a human typed it. But because AI watched the same ball, processed the same moment, and reacted, with personality, with timing, and with an opinion, in under two seconds. That's the Dream11 AI Companion. And building it was anything but simple. 🏆 World's first real-time AI sports streaming companion ⚡ ~2 second end-to-end voice latency 🗣 70+ languages supported natively by S2S model; primary: Hindi, English, Hinglish 🔌 Zero extra setup for streamers -- integrates directly via OBS + Creator Console What We Set Out to Build With 250M+ users, Dream11 has been on a journey to become everyone's sports entertainment destination. And entertainment lives where the fans are; inside live streams, creator channels, match-day conversations. The question we asked ourselves: What if a creator never had to stream alone again? Or if they were unavailable, could we ensure they had a back up? The answer was an AI Companion: A real-time, multilingual voice AI agent that joins live creator streams as a co-host. It watches the match. It reacts to what's happening. It banters with creators and audiences. It hosts trivia. It roasts players. It debates cricket. Meet the Characters Before we get into architecture, meet the two AI characters at the heart of this product. Bittu Bindas 🐻 A bold, banterous bear. Speaks Hindi (in Mumbaikar style). Playful, opinionated, and absolutely no-filter. Bittu doesn't overthink. He just says what every fan in the room is think ## From Static Catalogue to Smart Discovery: Engineering Lightning-Fast Search at DreamSetGo DevFeed: [From Static Catalogue to Smart Discovery: Engineering Lightning-Fast Search at DreamSetGo]() Original publisher: [Read original article]() Author: Dream Blog Published: 2026-03-09T13:50:30Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [PostgreSQL](), [Microservice](), [systems](), [elasticsearch]() Tags: [architecture](), [dream-sports](), [elasticsearch](), [engineering](), [open](), [performance](), [postgresql](), [search](), [search-engines](), [sports](), [tech](), [travel]() ### AI overview DreamSetGo's tech team explains how its growing sports-travel catalogue created a need for faster, more intuitive product discovery. The article describes rebuilding the catalogue as a microservice, considering PostgreSQL with Elasticsearch, and choosing PostgreSQL based on architectural and operational trade-offs. ### Source excerpt By the DreamSetGo Tech Team If you're excited about building high-performance systems that power premium sports travel experiences, explore our open roles at DreamSetGo. Why Search Became a Product Imperative Over the past couple of years, DreamSetGo's catalogue didn't just grow, it accelerated. We were introducing access to new tournaments, adding destinations across continents, and were expanding into different hospitality formats. What began as a few structured products quickly evolved into a layered catalogue of packages and experiences. And that's when we started noticing something subtle but important. Adding products was straightforward. Making them discoverable wasn't. Every new experience meant longer descriptions and richer metadata. On paper, this was definitely progress. But from a user perspective, it introduced friction. If a traveller already knew exactly where to click, they could navigate their way through the catalogue. But if they came in with intent like: "Wimbledon finals hospitality" "Hot air balloons in Cappadocia" "Scuba diving in the Andamans" ...there was no fast, intuitive way to show them the most relevant experience. Once we acknowledged this gap, the next step became clear: we needed a search system that was scalable, resilient, and fast enough to keep up with our growth. This blog takes you through how we designed that search, from architectural trade-offs to production optimisations, and why PostgreSQL turned out to be the best choice for this. The Obvious Architecture (That We Didn't Choose) We started revamping our architecture six months back and rebuilt our travel product catalogue as a dedicated microservice, one that would eventually power search, and filter it by date, price and more. At that point, we had roughly 1,000 products. But we weren't building for 1,000. We had a clear vision of significantly expanding the catalogue within the near future. Like most teams, our first instinct was predictable: PostgreSQL -> Source of Truth ## Engineering Features at Scale: Inside the Darwin Feature Store DevFeed: [Engineering Features at Scale: Inside the Darwin Feature Store]() Original publisher: [Read original article]() Author: Dream Blog Published: 2026-01-27T15:38:25Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [Feature Engineering](), [Low Latency](), [Apache Cassandra](), [Machine learning](), [Open Source]() Tags: [cassandra](), [data](), [engineering](), [feature-engineering](), [feature-store](), [inference](), [kafka](), [latency](), [machine-learning](), [offline](), [open-source](), [pipelines](), [software-engineering](), [tech]() ### AI overview Dream Horizon's Darwin Feature Store is an open-source, low-latency feature platform designed to support real-time machine learning and offline training at Dream11. The article describes the challenges that led to its development, including batch-only pipelines, manual schema changes, and scaling issues. It reports serving more than 200 million feature requests per minute with p99 read latency below 5 milliseconds and no production incidents over the preceding year. ### Source excerpt By Mohit Jain and Ujjwal Bagrania Dream Horizon, our open-source effort to make Dream11's battle-tested tech available to every developer, brings you the Darwin Feature Store -- a unified, low-latency feature platform built to power real-time ML at scale, and shaped to help teams build, manage, and trust features in production. Explore the Darwin Feature Store here. At Dream11, data and ML have always powered how millions of users experience sports in real time. From personalisation and relevance to ensuring efficiency under peak match traffic, ML sits deep in the critical path of the product. But models are only half the story. The real challenge is managing features -- how they're defined, versioned, and accessed consistently across training and live traffic, especially under peak sports pressure. And at the scale we operate at, feature access doesn't mean the occasional lookup; it means hundreds of millions of requests per minute, spanning both real-time inference and offline training pipelines. As Dream11 grew, feature engineering stopped being something we could manage with pipelines and tables, and became infrastructure that everything else depended on. That shift forced us to build the Darwin Feature Store: a system designed not just to tackle sports-scale traffic, but to make feature engineering predictable, reliable, and developer-friendly in production. Today, that translates into serving 200M+ feature requests per minute, delivering p99 read latencies under 5 ms, and doing so reliably through the most demanding live sports moments, without a single production incident over the last year. In this post, we'll walk through how we built the Feature Store, and what it takes to serve features reliably. The Early Days: Batch-Only, Fragile, and Manual Before the Darwin Feature Store existed, our feature engineering was mostly a few pipelines, a lot of Cassandra tables, and an increasing number of engineers building ML models. Here's what the first version looked li ## Lumos: Inside Dream11's Leap from Task-Based Models to Foundational Intelligence DevFeed: [Lumos: Inside Dream11's Leap from Task-Based Models to Foundational Intelligence]() Original publisher: [Read original article]() Author: Dream Blog Published: 2026-01-22T06:40:39Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [foundation-models](), [Sports](), [Machine learning](), [Large language models (LLMs)]() Tags: [analysis](), [competition](), [context](), [dream11](), [fragmentation](), [incremental](), [llm](), [ml](), [models](), [notifications](), [personalisation](), [scale](), [sports](), [systems](), [tech]() ### AI overview Dream11 describes Lumos, a foundation model for personalisation that connects user behaviour, context, and changing interests across sports experiences. The article reports a 2.5% lift in ROC AUC and a 4.6% reduction in MAPE across key tasks, while replacing dozens of task-specific systems with a single scalable foundation. ### Source excerpt By Dhruv Nigam At Dream11, our mission to 'make every match more exciting' starts with a simple truth: every fan experiences sport differently. Some users show up for marquee matches, while others engage consistently across the season. Some enjoy deep analysis; others come for emotion, banter, and shared moments. Even how fans prefer to be spoken to -- through in-app communication or notifications -- varies, from playful and expressive to direct and informational. In sports, context changes everything. A quiet weekday feels very different from the eve of a knockout match, and behaviour shifts with formats, rivalries, and the stage of competition. Personalisation at Dream11 therefore goes beyond surface-level customisation -- it's about understanding fans in motion and how their interests evolve. We've long recognised this challenge, but understanding and acting on these signals across millions of users, each with their own patterns and preferences, is far from easy. Over time, it became clear that small, incremental ML enhancements wouldn't get us where we needed to go. To stay truly user-first, we needed a system that could connect behaviour, context, and past, present, and future moments, all at once. That realisation led us to a ground-up rethink of how we build models at Dream11, and eventually, to Lumos -- our foundation model for personalisation. Lumos helped deliver a 2.5% lift in ROC AUC (Area Under the Receiver Operating Characteristic Curve) and a 4.6% reduction in MAPE (mean absolute percentage error) across key tasks, significantly improving personalisation, while replacing dozens of task-specific systems with a single, scalable foundation.The Problem: When Task-Based Models Stop Scaling For a long time, our personalisation stack relied on 50+ small, specialised models, each designed to understand a narrow aspect of user behaviour. Some models focused on sports affinity, others on language preferences or communication style. While these were effective in iso ## How AI is Changing the Way FanCode Builds, Tests and Ships DevFeed: [How AI is Changing the Way FanCode Builds, Tests and Ships]() Original publisher: [Read original article]() Author: Dream Blog Published: 2026-01-21T12:17:03Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [Artificial Intelligence](), [Development](), [pull-requests](), [Testing](), [Latency]() Tags: [ai](), [deployment](), [development](), [engineering](), [latency](), [pull-requests](), [software-engineering](), [sports](), [tech](), [testing](), [velocity]() ### AI overview FanCode describes how it has integrated AI into engineers' daily development workflows, including building, reviewing, testing, and shipping software for live sports. The article links this work to faster delivery and more reliable systems under load, while describing review delays and other growing pains in a lean engineering team. ### Source excerpt By Guruwinder Rishi and Pramod Kumar At FanCode, engineers work on problems that show up live -- in front of millions of fans -- and shape how sports are experienced in real time. If building, reviewing, testing, and shipping at scale excites you, we'd love to talk. Check out open roles at FanCode. At FanCode, engineering efficiency isn't an internal KPI. It's the difference between a fan watching a last-over finish without interruption and a stream dropping at the worst possible moment. When you're building for live sports, the margin for error is near zero. We stream 10,000+ live games every year, across sports, formats, and devices -- often with millions of fans watching at the same time. At that scale, every commit, every review delay, and every flaky test eventually shows up somewhere: in latency, stability, or how confident we feel pushing a change while a match is live. Behind the scale we operate is a lean 50 member engineering team across backend, frontend, and testing -- and that's by design. The problem we've been solving for years isn't scale through headcount. It's scale through clarity, velocity, and trust in our systems, while still giving engineers the space to learn, iterate, and do some fantastic work. We've been using AI across FanCode for a while now. But what's changed over the last year is how deeply we've started integrating it into the everyday lives of engineers. This blog outlines the changes we've made to our development workflows, how we used AI, and the results we saw in terms of faster delivery and more reliable systems under load. With Scale, the Cracks That Started to Show As FanCode scaled, we began facing the classic growing pains of a fast-moving, high-output tech team. Inefficiencies that were manageable earlier started compounding quickly, and a few patterns became impossible to ignore. I. The Review Bottleneck: Pull requests routinely took 2-3 days to move from "raised" to "merged". On their own, such delays didn't seem alarming. Bu ## A Day in the Life of Ayush Sharma, DevOps Engineer at FanCode DevFeed: [A Day in the Life of Ayush Sharma, DevOps Engineer at FanCode]() Original publisher: [Read original article]() Author: Dream Blog Published: 2025-12-24T07:59:51Z Content type: opinion Language: en Sources: [Dream11 Engineering]() Topics: [DevOps](), [Cloud](), [Linux](), [observability](), [dashboards](), [Latency](), [Security](), [Shell]() Tags: [culture](), [dashboards](), [devops](), [employee-experience](), [engineering](), [latency](), [linux](), [observability](), [security](), [sports]() ### AI overview A personal account of Ayush Sharma's work as an SDE-3 in DevOps at FanCode. The article describes his background, his transition from Linux and shell scripting to cloud-focused work, and his daily routines for monitoring systems, supporting teams, maintaining security, and helping keep streaming experiences reliable. ### Source excerpt If you're excited about building reliable, real-time experiences for millions of fans, we're hiring across FanCode. Explore open roles and come build with us. I grew up in a defence family in the same state that gave the world MS Dhoni. Sports wasn't a hobby; it was the air we breathed -- basketball on rough courts, kabaddi on dusty grounds, football and cricket wherever there was space. That mix of discipline and play shaped the way I work even today. Off the field, I was the kid who buried himself in esports matches and gadgets. Scrims taught me the value of low latency, clear comms, and decision-making under pressure. I didn't know it back then, but those instincts would later define my DevOps career. Before cloud was my day job, Linux was my playground. I fixed permissions on messy shared hosts, learned how logs speak when something's wrong, and wrote small shell scripts to make life easier. In college, I even stitched together a tiny "cloud" using a bunch of friends' laptops -- half experiment, half curiosity. Seven years later -- five of which I've spent at FanCode -- I'm here as an SDE-3 in DevOps, driven by one promise: make speed feel safe. Inside the company, my end users are the people who design, build, test, analyse, ship and secure our products. Outside, our fans just expect the stream to work. And my job is to make that seamless. How I Run My DayStart: Steadying the Field I like to ease into the day with a simple ritual: coffee in hand and a quick health sweep of the system. Before diving into any work, I read through the on-call handover to understand what unfolded overnight, not just what alerted, but how the system behaved. From there, I open our observability board and look at alerts and our key dashboards for patterns. These early clues help me understand if some team or process is blocked, or if a fan is facing an issue and address that immediately. I also go through requests from other teams -- tickets, a product experiment that needs support, a pip ## Inside the Tech That Powers Dream Cricket's Multiplayer Experience DevFeed: [Inside the Tech That Powers Dream Cricket's Multiplayer Experience]() Original publisher: [Read original article]() Author: Dream Blog Published: 2025-12-13T07:38:59Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [Kubernetes](), [cloud-infrastructure](), [Open Source](), [Server]() Tags: [architecture](), [cloud](), [cricket](), [deploy](), [game-development](), [game-servers](), [games](), [gaming](), [high-performance](), [infrastructure](), [kubernetes](), [latency](), [multiplayer](), [open-source](), [production](), [scale](), [tech]() ### AI overview This article describes how Dream Cricket scaled its multiplayer infrastructure after a simple queue and fixed server pool could no longer handle growing adoption and large-scale events. It discusses challenges including peak matchmaking delays, unfair pairings, idle capacity, risky rollouts, and limited operational visibility, then outlines a design using Open Match, Agones, Kubernetes, and a health and latency service. ### Source excerpt By Vaibhav Naik Every great game starts with great tech -- and great people behind it. If you're passionate about crafting seamless, high-performance gaming experiences that bring players closer to the sport they love, we'd love to have you on our team. Explore our open roles at Dream Cricket. Why Multiplayer Matters on Dream Cricket We've always believed that the best games are the ones that bring people together. And that's exactly what multiplayer on Dream Cricket does -- it turns gaming from a solo challenge into a shared moment. The banter, the thrill of a close finish, the satisfaction of a fair match -- that's what keeps players coming back. Over the years, as our player base grew and expectations rose, we knew our multiplayer system needed to be scaled. It had to be faster. Fairer. The kind of system that doesn't break under pressure, whether it's lakhs of players logging in during a live event or two friends battling it out over spotty mobile data. This blog is our story of getting there. It's about how we rethought everything, from how we match players to how we run thousands of servers all at once. You'll get a look at the roadblocks we hit, the calls we had to make, and how open-source tech like Open Match and Agones helped us build something truly scalable. Building for the Next Era of MultiplayerThe Challenge Our initial multiplayer setup used a simple queue and a fixed pool of servers, which worked well. As adoption grew and large-scale events became frequent, the system was unable to manage the load. We had to move from basic matchmaking to skill-based fairness, surge handling, safe releases, and cloud portability. And as we scaled, familiar pain points surfaced: High P95 time-to-match at peak; cancellations rose Unfair pairings in upper tiers; noticeable re-matches Idle server waste off-peak; slow warm-up during spikes Risky rollouts without clean canaries; limited on-call visibility The challenge was clear: we needed to decouple matchmaking logic from ## Dream UTT Juniors: Building India's Next Generation of Table Tennis Champions DevFeed: [Dream UTT Juniors: Building India's Next Generation of Table Tennis Champions]() Original publisher: [Read original article]() Author: Dream Blog Published: 2025-12-13T07:05:51Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [Sports]() Tags: [2025](), [collaboration](), [community](), [competition](), [dream-sports](), [india](), [platforms](), [sports](), [table-tennis](), [visibility](), [youth-sports-development]() ### AI overview The article describes Dream UTT Juniors, a collaboration between Dream Sports Foundation and Ultimate Table Tennis to give India's U-15 table-tennis players experience competing in a professional-league environment. It explains how sixteen players from the Dream Sports Championship: Table Tennis were drafted into UTT franchises and reports that the league was streamed on FanCode. ### Source excerpt At Dream Sports Foundation (DSF), our goal has always been simple: to make sports better by strengthening India's sporting ecosystem and creating opportunities that truly matter. From cricket and football to boxing and weightlifting, we've worked across sports, supporting their growth through high-impact programmes and partnerships that enable athletes to perform at their best. As we continued to expand our focus, we also began exploring Olympic and high-potential sports where structured, high-quality competitions could make a meaningful difference. That's how table tennis found its way into our plans -- a sport with immense potential in India, yet limited access to professional-level platforms for young athletes. The idea was to bridge that gap, to create an opportunity that allows young players to experience the intensity, standards, and spirit of a professional league early in their journey. The outcome was Dream UTT Juniors -- a collaboration between DSF and Ultimate Table Tennis (UTT). How Dream UTT Juniors Came to Life Sometimes, all it takes is one question to spark something extraordinary. For us, it began with a simple idea shared between DSF and UTT: "What if India's U-15 players could experience the thrill of a professional league, just like seasoned players?" That question set everything in motion. What started as a passing thought quickly turned into a shared mission -- to create a platform where India's most promising U-15 talent could play and compete like professionals. By early 2025, DSF's own Dream Sports Championship: Table Tennis, held in association with the Table Tennis Federation of India (TTFI), had already taken place -- bringing together remarkable young talent from across the country in a first-of-its-kind competition. The top sixteen players from that tournament were then drafted into the UTT franchises (U Mumba TT, Stanley's Chennai Lions, PBG Pune Jaguars, Kolkata Thunder Blades, Jaipur Patriots, Dempo Goa Challengers, Dabang Delhi T.T.C., ## Odin: Dream11's Open-Source Deployment Platform Built After Jenkins Deployment Challenges DevFeed: [Odin: Dream11's Open-Source Deployment Platform Built After Jenkins Deployment Challenges]() Original publisher: [Read original article]() Author: Dream Blog Published: 2025-12-11T07:55:37Z Content type: article Language: en Sources: [Dream11 Engineering]() Topics: [Deployment](), [Jenkins](), [DevOps](), [Open Source](), [Testing](), [Microservice]() Tags: [deployment](), [developer](), [devops](), [dream-horizon](), [jenkins](), [microservices](), [open-source](), [tech](), [testing]() ### AI overview This article introduces Odin, Dream Horizon's open-source deployment platform from Dream11. It describes how Dream11 evolved from numerous Jenkins jobs to a deployment system intended to support building, testing, and deploying services through on-demand environments. The article identifies job complexity, limited support for virtual machines and Kubernetes, and the lack of a unified deployment-lifecycle vision as challenges in the earlier setup. ### Source excerpt By Suraj Gour and Ankit Pare Dream Horizon, our open-source effort to make Dream11's battle-tested tech available to every developer, brings you Odin -- a high-performance deployment platform that lets developers build, break, test, and ship smarter and more efficiently. Explore Odin here. Deployments at Dream11 have come a long way. From Jenkins jobs to on-demand environments, we have reimagined how services are built, tested and deployed. With Odin -- our new deployment system -- developers define what they need and deploy with confidence in seconds. This evolution started with key lessons from our earlier setup. Navigating Jenkins Mayhem: When Jobs Ran Wild It was a regular day at Dream11. A new joiner was browsing onboarding documents, trying to understand how to test their code alongside other dependent microservices, and then eventually deploy it live in production. They simply asked their teammate how to proceed. Here's how their conversation went: The newly joined developer (looking perplexed) asked: "My code is master-merged. How can I test the complete user authentication flow? And what are the steps I need to follow to get my feature live in production? I can't seem to find any documentation around this."The teammate (with a sympathetic sigh) replied: "Come with me. Let's talk to the DevOps team. They'll guide you and take you through the process."Upon reaching the DevOps team, our developer presented their request.The DevOps team (calmly, with the weariness of having answered this question several times) responded: "You want to push this code to production? Alright. We have a set of Jenkins jobs for this."The newly joined developer asked again: "And what about testing in a dev environment and performing a load test?"The DevOps team replied: "For load tests, we have... guess what... separate jobs!" Jenkins jobs introduced more complexity than clarity. More jobs meant greater uncertainty and longer turnaround times. Given our use case, we were running into recurr