# blinkit Published articles for blinkit. 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.