# Grofers All about engineering at Blinkit --India's beloved instant delivery platform. - 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 INTEGER and INT Produced Different Schemas in Debezium DevFeed: [How INTEGER and INT Produced Different Schemas in Debezium]() Original publisher: [Read original article]() Author: Prathit Malik Published: 2026-09-02T07:02:02Z Content type: article Language: en Sources: [Grofers]() Topics: [MySQL](), [migration](), [Streaming](), [Kafka](), [SQL](), [Databases]() Tags: [big-data](), [blinkit](), [change](), [database](), [debezium](), [jdbc](), [kafka](), [migration](), [mysql](), [open-source](), [schema](), [sql](), [streaming]() ### AI overview This article investigates a Debezium CDC pipeline failure caused by MySQL INT and INTEGER synonyms being treated as different types. The resulting schema mismatch produced an Integer where a downstream consumer expected a Long, causing a ClassCastException on every batch. It explains how streaming and snapshot schema handling differ and how routine migrations exposed the problem. ### Source excerpt A Debezium investigation: how MySQL synonyms INT and INTEGER were treated as different types. One of our CDC pipelines started failing with a ClassCastException on every batch. java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.Long The pipeline was producing an Integer, but the downstream consumer expected a Long. Every run failed in the same way, which pointed us toward a schema mismatch rather than an issue with individual records. Background: how CDC works To see why a mismatch like that can hide for years, it helps to know how CDC actually works. Most companies replicate their transactional database (MySQL, Postgres, something similar) into a separate data lake for analytics, rather than querying the source directly, and Change Data Capture (CDC) is what keeps that copy in sync: it tails the database's transaction log and replays every insert, update, and delete downstream. Debezium is the most widely used open-source CDC tool for MySQL, and it builds a table's schema in one of two ways that are supposed to agree but do not always. Streaming mode: the first time it sees a CREATE TABLE or ALTER TABLE in the binlog, it parses the raw SQL text and writes the result to its own internal Kafka topic, database.history.kafka.topic. Every restart after that rebuilds the in-memory schema by replaying that topic, not by re-reading the binlog. Snapshot mode: reads the table definition fresh through MySQL's JDBC metadata interface, which normalizes types, every time it runs. Schema Registry sits downstream of both: each connector writes whatever schema it built into the registry, but neither connector reads its own schema back from it. Keep that in mind; it matters later. The trigger: a routine migration With that in mind, here's what actually happened to us. Rewind two years: one of our upstream service teams added a few columns to a source table as part of a standard schema change. ALTER TABLE ADD COLUMN length double NU ## Blinkit at OpenSearchCon India 2026 DevFeed: [Blinkit at OpenSearchCon India 2026]() Original publisher: [Read original article]() Author: Harshit Prasad Published: 2026-07-24T10:16:24Z Content type: article Language: en Sources: [Grofers]() Topics: [opensearch](), [migration](), [linux foundation]() Tags: [2026](), [architecture](), [blinkit](), [community](), [conference](), [data](), [distributed-systems](), [engineering](), [india](), [keynote](), [linux-foundation](), [migration](), [opensearch](), [scale](), [search](), [software-engineering]() ### AI overview Blinkit describes its OpenSearchCon India 2026 keynote, including its migration from a single OpenSearch cluster to a multi-cluster architecture, the production challenges encountered, and the trade-offs and lessons shared with the community. ### Source excerpt A few weeks ago, we spoke at OpenSearchCon India about how we make search fast and reliable at scale at Blinkit. I'm Harshit, from the Search Engineering team at Blinkit, and this year we got to speak at OpenSearchCon India at the Jio World Convention Centre in Mumbai. In this post, I'll walk you through our talk, the conversations that followed, and what our team took away from being part of the OpenSearch community in a more active way this year. First Day : Keynote by Blinkit The highlight of this year's conference for our team was the opportunity to deliver a keynote session at OpenSearchCon, organised by the Linux Foundation. Along with my fellow engineer Bharti Sawaria we walked the audience through our journey of migrating from a single OpenSearch cluster to a multi-cluster architecture. We shared the challenges we faced, the solutions that failed in production, and our key learnings for the community. We also discussed Blinkit's growing scale & the trade-offs we made during our migration. To provide context for our global audience, we framed the talk around the sheer scale at which we operate, highlighting the "breaking point" where we realised a single cluster could no longer handle our needs. Bharti explaining about OpenSearch Multi-Cluster ArchitectureHarshit explaining about the OpenSearch Single-Cluster Architecture The official keynote talk video can be found on Youtube : https://medium.com/media/774b8379733c6442d3ecaa3976c2191e/hrefThe Experience at OpenSearchCon Beyond the breakout sessions, the real value of OpenSearchCon was connecting with engineers from across the industry. Many of whom are dealing with similar scale and freshness challenges, openly sharing what's worked and what hasn't. That kind of unfiltered peer exchange is hard to replicate online. Our team attended multiple breakout sessions and had several great discussions with engineers from Uber, Freshworks, Oracle, and others. A few sessions stood out enough to flag once recordings are ## A Blinkit iOS Engineer's Experience at Apple Park and WWDC 2026 DevFeed: [A Blinkit iOS Engineer's Experience at Apple Park and WWDC 2026]() Original publisher: [Read original article]() Author: Singh Ayush Published: 2026-06-29T12:01:28Z Content type: article Language: en Sources: [Grofers]() Topics: [iOS](), [Swift](), [Artificial Intelligence](), [macOS](), [iphone](), [Google]() Tags: [2026](), [ai](), [apple](), [blinkit](), [google](), [ios](), [iphone](), [macos](), [performance](), [swift](), [wwdc]() ### AI overview An iOS Engineer at Blinkit recounts attending WWDC 2026 in person at Apple Park and describes the event, keynote experience, Siri AI announcements, claimed performance improvements for iOS 27 and macOS 27, and support for older iPhones. ### Source excerpt Every June, developers around the world tune in to Apple's Worldwide Developers Conference (WWDC) to see what's next for Apple's platforms. This year, I had the opportunity to experience it in person at Apple Park and it was a week I'll never forget. As an iOS Engineer at Blinkit and a long time member of the Apple developer community, WWDC26 felt like the perfect intersection of two things I love "building products and learning from some of the best engineers and creators in the world". Hi, I'm Ayush Singh, an iOS Engineer at Blinkit and a four-time winner of the Apple Swift Student Challenge and I'm writing this blog to share some of the moments and learning from an unforgettable week. First Impressions of Apple Park Watching keynotes online and following WWDC announcements from afar, being there among thousands of developers felt incredibly special. The campus was filled with excitement as developers, students, creators, and engineers from around the world gathered to celebrate another year of innovation. Experiencing the Keynote Live No WWDC experience would be complete without the keynote itself. Watching the WWDC26 keynote at Apple Park was an entirely different experience from watching it online. Here is the announcements stood out to me as both a developer and someone building products at Blinkit. If you missed the announcements, here's a quick read. 1. Siri AI For years, Siri has felt like a voice shortcut that occasionally set timers or checked the weather. No more. Apple has completely rebuilt Siri from the ground up, moving away from adding on features to a deep, system wide AI architecture. The new Siri AI is designed to understand you better than ever: On-Screen Awareness Deep Personal Context Siri got a dedicated app Google gemini as a third-party brainpower 2. Performance Apple didn't just add new features; they tightened the screws on the underlying software. Apple claims that iOS 27 and macOS 27 will launch apps up to 30% faster, load photos 70% fa ## Diagnosing a Deadlock in Trino's Hudi Connector That Stalled Blinkit's Inventory Pipeline DevFeed: [Diagnosing a Deadlock in Trino's Hudi Connector That Stalled Blinkit's Inventory Pipeline]() Original publisher: [Read original article]() Author: Ratul Dawar Published: 2026-05-29T09:26:27Z Content type: article Language: en Sources: [Grofers]() Topics: [Deadlock](), [Concurrent Programming](), [Amazon S3]() Tags: [apache-hudi](), [big-data](), [blinkit](), [bug](), [deadlock](), [open-source](), [s3](), [thread](), [trino](), [trinos](), [yield]() ### AI overview Blinkit describes how a deadlock in Trino's Hudi connector stalled inventory replenishment queries without errors or resource saturation. The issue involved one thread pool handling both file-split production and signalling; the reported fix used cooperative scheduling and was contributed upstream. ### Source excerpt A silent deadlock in our query engine was stalling inventory replenishment jobs with no error, no crash -- just infinite waiting. This is the story of how we found it, traced it to an open-source bug, and fixed it upstream. TL;DRTrino's Hudi connector used a single thread pool for both producing file splits and signalling when there was room for more. Under load, every thread ended up waiting for a signal that had no thread left to run it. The fix was to switch the producer side to a cooperative scheduling pattern: yield the thread when the buffer is full, and resume when space opens. Our inventory replenishment pipeline was frozen. CPU was idle. Memory was fine. There were no errors anywhere. Queries just... stopped moving. The first signal was a long queue on one of our analytics clusters. Queries were piling up. Inventory replenishment jobs -- the jobs that decide how much stock every warehouse and store needs to hold -- were delayed. Blinkit's supply chain was being impacted. Dashboards were turning amber, but nothing was crashing. That was the unsettling part. Investigation: Resources Doing Nothing The affected cluster runs analytical workloads on Trino, reading data stored in Apache Hudi tables on S3. The natural first instinct in a queue build-up is to look at resource saturation -- a CPU spike, memory pressure, network bottleneck. There was none of that. The cluster was sitting largely idle, with CPU barely above baseline and heap usage well within limits. Every new query touching a Hudi table joined the queue and stayed there indefinitely. Queries that were already mid-execution completed fine. Only freshly submitted ones were affected. And crucially, there were no errors. No timeouts, no exceptions in the logs -- just silence and a growing backlog. A thread dump -- a snapshot of what every thread in the process is doing right now -- was our next move. It showed dozens of producer threads all stuck in the same parked state, waiting on the exact same internal signal. ## How Blinkit's Droid Dex Adapts Android App Performance to Device Capabilities DevFeed: [How Blinkit's Droid Dex Adapts Android App Performance to Device Capabilities]() Original publisher: [Read original article]() Author: Karan Gourisaria Published: 2025-06-26T07:03:41Z Content type: article Language: en Sources: [Grofers]() Topics: [Android](), [Optimization](), [Development](), [real-time](), [Caching](), [User experience (UX)]() Tags: [adaptive](), [android](), [android-development](), [anr](), [app-performance](), [caching](), [engineering](), [fragmentation](), [kotlin](), [mobile-development](), [performance](), [real-time]() ### AI overview This article describes Blinkit's Droid Dex, a system that classifies device performance and adapts Android app behavior accordingly. It presents device fragmentation as a source of out-of-memory errors, slower screen rendering, and ANRs, and describes adaptations such as concurrency limits, caching levels, power-saving mode, and simplified animations. ### Source excerpt How Blinkit Cracked Android's Performance Puzzle with Droid DexAdaptive real-time performance tuning -- fewer ANRs, smoother UX, and smarter device-specific optimization Picture this: Your app runs buttery-smooth on Pixel 7 Pro while throwing ANRs on a Redmi Note 4. Users on a Fold 6 have to experience the same janky transitions as those on a INR 6,000 device. Sounds familiar? Welcome to Android development in 2025, where device fragmentation is one of the biggest challenges. This is the story of how Blinkit solved Android's most notorious problem: intelligent, real-time performance adaptation. 📱 The Problem: One Codebase, Infinite Devices Device Fragmentation isn't just a developer headache -- it's a business liability. At Blinkit, we serve millions of users across India's most diverse Android ecosystem, from ultra-budget to flagship devices. Consider these jaw-dropping stats from our production data: 57% of total OOMs occur on devices with less than 4GB of RAM The average time to render key screens is 2.5 times slower on budget phones compared to flagships 20% of users drop off after experiencing a single ANR Traditional solutions? They're all broken: 🔴 The Conservative Trap: Design for the weakest device. Result? Premium users get a subpar experience. 🔴 The Aggressive Fallacy: Optimize for flagships. Result? 60% of users face OOMs and ANRs. We needed something better -- something smarter, that could make apps think about performance in real-time. 🔥 Introducing: Droid Dex Imagine your app could sense the device it's running on and instantly adapt: "This phone can handle 4 concurrent videos, aggressive caching, and premium transitions" or "This device needs power-saving mode, minimal caching, and simplified animations"? That's exactly what Droid Dex does. It's not just another performance library -- it's an intelligent performance classification system that lets your app adapt to its environment. // Make your app performance-aware with a single call DroidDex.getPerformanc ## India's First Instant Print Store DevFeed: [India's First Instant Print Store]() Original publisher: [Read original article]() Author: Jacob Published: 2023-05-22T07:27:07Z Content type: article Language: en Sources: [Grofers]() Topics: [Raspberry Pi](), [Internet of things](), [Microservices](), [Security](), [Automation]() Tags: [automation](), [backend](), [engineering](), [hardware](), [india](), [iot](), [microservices](), [paas-solutions](), [quick-commerce](), [raspberry-pi](), [security](), [software]() ### AI overview This engineering case study describes an instant print delivery service built with Raspberry Pi devices connected to local printers. It explains how the team addressed hardware reliability, privacy and security, automation, issue detection, and service uptime while integrating the store with existing microservices. ### Source excerpt Leveraging IoT to deliver printouts to your doorstep Setting up our Printout Delivery Store has been highly satisfying. At one end is the joy of customers discovering an easy, home-delivered solution for last-minute printouts. But even more enjoyable is the knowledge that we created a nationwide service with only a Raspberry Pi and a seamless print flow that effectively harnesses the power of our instant delivery. But we did face some challenges along the way. Post-launch, our customers started experiencing many consistency issues, which had to be fixed before we could scale this service. These challenges stemmed from fundamental hardware limitations. Combined with a need for data privacy and security, it led to frequent misses. The root causes were silly things, such as printers not connecting to the Internet, going to sleep, running out of paper, etc. Below are ways we tackled them and made the instant print store a success. What did we need to do? We needed to figure out how to tinker with our existing microservices to integrate them with the Print Store. Hence we set aside the following objectives: Automation: Start the print process once the order has cleared its payment without manual intervention. Security: Delete the files as soon as the print is complete. Agile Response System: Build a detection mechanism to act quickly on issues such as paper jams and low toner levels 99.9% Uptime: Have No service downtime whatsoever. Selecting our Hardware -- Slice of Pi We needed inexpensive, IoT-friendly hardware, naturally drawing us to the lean, mean, fruity machine-The Raspberry Pi. The Pi is the epitome of commodity computing. It's cost-effective, energy-efficient, easy to set up, and has a ton of support for peripheral connectivity. With the Raspberry Pi, we can also sandbox and package our services to be deployed remotely nationwide. Our Software ImplementationStore Printing Controller Service This service is the heart of our operation and runs on our Pi Zeros (run ## In Focus: Blinkit SRE Engineer Sumanth Reddy on Resilient Software and Scalable Database Migrations DevFeed: [In Focus: Blinkit SRE Engineer Sumanth Reddy on Resilient Software and Scalable Database Migrations]() Original publisher: [Read original article]() Author: Jacob Published: 2023-03-16T03:21:01Z Content type: article Language: en Sources: [Grofers]() Topics: [Resilience](), [SRE](), [DevOps](), [Database]() Tags: [culture](), [database](), [devops](), [engineering](), [people-at-blinkit](), [quick-commerce](), [resilience](), [site-reliability-engineer](), [sre]() ### AI overview An interview with Blinkit SDE 3 Chinthakunta Sumanth Kumar Reddy about his journey, work in Software Resilience Engineering, scalable database migrations, resilient software, and challenges in the instant commerce space. ### Source excerpt A conversation with engineers who help run Blinkit Chinthakunta Sumanth Kumar Reddy is an SDE 3 at Blinkit. He joined us in March 2021 and has since helped us build a resilient application platform at Blinkit. He currently works as a part of Software Resilience Engineering (SRE)-enabling scalable database migrations for Blinkit's applications. Tell us about your background and your journey in Blinkit so far. I have always been curious to learn new things and don't have barriers as long as I can engage with the task. Hailing from a small village in Andhra Pradesh, I have travelled across several cities (Fun fact: My village and family share the same name). I have been working with the SRE team for almost two years. I love the no-nonsense work culture here, which allowed me to raise PR from day 2 in the company. Why did you choose to work in tech? What drove you? Due to my background in the Electronics branch, I have always been fascinated by how the physical transistors click and clack with seemingly intangible software bits. There is a sense of excitement when things spring into action, and I think if there's an equivalent of magic in our world, it will be Tech. What excites you the most about your field? The ability to build resilient software excites me. Imagine seeing a traffic spike and everything scaling up to take the load and winding down when the traffic calms down, all on its own-It's magical, to say the least. While solving a problem, what is the principle you always adhere to? When hit with a problem, take a step back and think through it. Sometimes, it isn't what it appears to be. Problem-solving is all about perspectives. What immediate challenges are we trying to solve in the instant commerce space? Efficiency and localisation. With delivery timelines moving from days to minutes, there is significantly lesser room for errors. Also, since we are nearer to customers, localisation is the key. For example, a top seller in one area might be utterly irreleva ## Make your reports faster : Beginner's guide to Tableau Optimization DevFeed: [Make your reports faster : Beginner's guide to Tableau Optimization]() Original publisher: [Read original article]() Author: Akash Vishwakarma Published: 2023-03-07T15:58:04Z Content type: tutorial Language: en Sources: [Grofers]() Topics: [Optimization](), [dashboards](), [data](), [real-time](), [Tool]() Tags: [dashboards](), [data](), [data-analysis](), [data-visualization](), [guide](), [optimization](), [real-time](), [reporting](), [tableau]() ### AI overview A beginner-oriented guide to improving Tableau dashboard performance. It covers performance recording, filtered or sampled extracts, data-source connections, live versus extract queries, and context filters. The article reports reductions in render or load time, extract time, and improvements in view throughput at Blinkit. ### Source excerpt Make your reports faster: A beginner's guide to Tableau Optimisation In today's world, given the pace at which data operates, we need a tool that can help us to generate reports faster and bring out insights within milliseconds. In order to solve this challenge, several companies have started utilising a few Business Intelligence (BI) tools such as Tableau/Power BI/Superset/Looker/Qlikview, etc. We at Blinkit have also moved away from the traditional way of reporting via spreadsheets to a more scalable and robust tool -- Tableau. Earlier, we had no single source of truth for metrics; it took a significant amount of manual effort to compile data in spreadsheets, and we were frequently limited by our local memory. Theoretically, Tableau can handle data up to ∞ rows and columns. However, it slowly begins to slow down as it renders calculations, fields, and formulas. At Blinkit, tracking supply and consumer metrics in real-time is the need of the hour. The faster we track, the faster we decide and move forward. Given below are some hacks that enabled us to achieve a significant improvement in the performance of our dashboards. The effects have been noted across various aspects of our operations, including but not limited to: Reduction in the average render/load time by over 50% in the last six months. Over a three-fold improvement in throughput in traffic to views in the last three months. A 50% reduction in the extract time over the last six months. Check performance recording This is the first step in identifying the problem. The performance recording gives information about key events as you interact with a workbook. Further details can be found here. Fig. 1: Start Performance Recording in TableauFig. 2: Events Sorted by TimeGenerating extract To speed up extract generation, consider importing only some data from the original data source by using filters or importing a limited sample of data. Connecting to data sources Slow connections could be due to network issues o ## In Focus: Jay Dihenkar DevFeed: [In Focus: Jay Dihenkar]() Original publisher: [Read original article]() Author: Jacob Published: 2023-02-23T03:01:29Z Content type: opinion Language: en Sources: [Grofers]() Topics: [release engineering](), [SRE](), [CI/CD](), [Resilience](), [Monitoring](), [observability](), [developer-productivity](), [Automation](), [Scalability](), [systems]() Tags: [automation](), [ci-cd](), [culture](), [developer](), [developer-productivity](), [devops](), [monitoring](), [observability](), [people-at-blinkit](), [quick-commerce](), [release-engineering](), [resilience](), [scalability](), [site-reliability-engineer](), [sre](), [systems]() ### AI overview An interview with Blinkit Staff Engineer Jay Dihenkar about his journey from release engineering to site reliability engineering. He discusses CI/CD, developer productivity, production incident debugging, automation, monitoring and alerting, infrastructure costs, application reliability patterns, and challenges in scaling quick-commerce logistics. ### Source excerpt A conversation with engineers who help run Blinkit Jay Dihenkar is a Staff Engineer at Blinkit. He joined us in December 2020 and has helped different teams manage and streamline their build and release processes. He is currently working towards continuously improving the reliability, scalability, observability, developer productivity, and other such aspects of a software system critical for ensuring that the system can meet the needs of its users and stakeholders over time. Tell us something about yourself and your journey in Blinkit so far. I started out as an engineer on the Release Engineering team, working on goals of Software Quality/Stability and streamlining release processes (Continuous Integration/Continuous Deployment or CI/CD). I help make an impact by improving developer productivity while safeguarding the production ecosystem against failures. I later transitioned into the Site Reliability Engineering (SRE) team, where we focused on improving the reliability and resilience of our systems. Being a site-reliability engineer requires one to develop a deep understanding of how the various components of a system work together and how to optimize them. Overall my journey in Blinkit is one of continuous learning and improvement. If you were to describe your experience as a Blinker in one word, what would that be? Growth. Being here is all about continuous learning in a fast-paced environment. What does a typical day at work look like for you? On a typical day, I work on the following domains (though not everything on a single day!): debugging complex problems sprung out of production incidents, putting automation in places where required, setting up monitoring and alerting, as well as responding to alerts, release engineering and developer productivity (CI/CD), System Infrastructure Cost, Working toward implementing Application Reliability Patterns and so on... What are the biggest challenges facing quick commerce today? I believe the "Logistics infrastructure"