Swiggy's Fan-tastic Search for Blazing Fast Results
Original post Fan-tastic Search for Blazing Fast Results
Article Summary
Swiggy's search feature was a mess: 2,000+ lines in a single ViewModel, monolithic XML files, and performance issues. Time for a complete rewrite.
The Swiggy Android team rebuilt their search module from scratch, introducing backend-driven UI, Protobuf instead of JSON, and breaking monolithic components into reusable widgets. This deep dive shares the architectural decisions and measurable performance wins.
Key Takeaways
- Switched to Protobuf: 11.85% smaller response size and faster load times
- Backend-driven UI with presentation layer controls widget positioning across screens
- Broke 2K line ViewModel into reusable components shared between home and search
- GPU overdraw dramatically reduced by replacing custom views with modular XML layouts
- Memory footprint cut: 34 bitmaps down to 19, fewer layouts and widgets
The rewrite delivered measurable performance gains across GPU rendering, memory allocation, and response times while making the codebase maintainable and scalable.
Continue reading
What This Article Covers
Swiggy's search module had a problem. Every sprint brought changes to analytics events, which meant the app needed new releases. The analytics logic was built directly into the client code, making it hard to separate concerns.
Viswanathan K P's team moved analytics to the backend. They added an analytics block to each list item contract. This let them configure events without pushing app updates.
The team stopped needing new app releases to fix analytics issues. Deployment cycles got shorter and they could adjust events in real time when new features launched.
This page summarizes “Fan-tastic Search for Blazing Fast Results” by Swiggy, published Dec 20, 2022. All credit for the original work goes to the authors.
