Presenters

Source

From Latency to Luxury: How gRPC Revolutionized Our Real-Time Ad Analytics 🚀

In the split second it takes for a webpage to load, a silent, high-speed auction occurs. This is Real-Time Bidding (RTB). While you wait for the news to pop up on The Times of India, advertisers are battling in a virtual marketplace to show you the most relevant ad. Behind this seamless experience lies a massive engine of data, and today, we are diving deep into how we optimized that engine using gRPC.

🌐 The High-Stakes World of Digital Advertising

To understand our architectural choices, we first need to look at the ecosystem. On one side, we have Publishers (apps or websites with empty ad spaces) connected via Supply-Side Platforms (SSP). On the other, we have Brands and Advertisers using Demand-Side Platforms (DSP) to buy those spaces. In the middle sits the Ad Exchange, the virtual marketplace facilitating the auction.

Our team manages the analytics for a DSP, helping customers make efficient decisions across display, video, and connected TV (CTV) channels. We handle a massive hierarchy:

  • Campaigns: Defining budgets and durations.
  • Packages: Grouping placements for optimization.
  • Placements: Targeting rules for specific ad types.
  • Ads: The actual creative units and tracking URLs.

📊 The Challenge: Visualizing Mountains of Data

We support two primary dashboards that demand extreme performance:

  1. Campaign Dashboard 📈: Our default landing page. It supports 97 metrics (like CPM, impressions, and spend) with a time window of up to 2 years. It handles thousands of rows and allows data export in XML format.
  2. Insights Dashboard 💡: A multi-tab view for deep dives into reach and conversions. It supports 75 metrics and 20+ dimensions across a 3-month window, offering dynamic filters and interactive visualizations.

Initially, our reporting was powered by a traditional REST setup. However, as data grew, we faced a choice: stick with the status quo or evolve. We chose evolution.

🛠️ The Architecture: Enter gRPC

Our reporting application is a gRPC-based microservice. Because browsers cannot natively talk to gRPC easily, we use a Routing Layer.

  • The UI sends a REST request.
  • The Routing Layer generates a Protobuf request.
  • The Dashboard Reporting Service fetches data from Druid, Delta Lake, and SQL.
  • Data is aggregated and sent back as a Proto response, then converted back to REST for the UI.

Performance Benchmarks ⏱️

  • Report Requests: Average response time of 812 milliseconds (handling a large number of metrics).
  • Time-Series Requests: Average response time of 353 milliseconds (optimized for fewer dimensions).

⚡ Why gRPC? The Technical Edge

While REST served us well, gRPC provided the efficiency required for daily and hourly reporting at scale. Here is how we leveraged its core features:

1. The Power of Protobuf 📝

Everything starts with a .proto file—a strict contract between client and server. We use repeated string columns to handle our dynamic dashboards efficiently. Instead of messy arrays with commas and quotes, Protobuf sends data in a streamlined format.

  • The Result: A JSON request of 4,247 bytes shrinks to just 1,180 bytes in binary. That is a 72% decrease in payload size! 📉

2. Server-Side Streaming 🌊

Instead of sending one massive, blocking block of data, our server streams results incrementally:

  • Column Headers arrive first.
  • Data Rows (e.g., 30 days of data) follow one by one.
  • Summaries and Pagination info wrap it up.

3. HTTP/2 and Multiplexing 🚥

gRPC uses HTTP/2, allowing us to use a single TCP connection for multiple parallel streams. We defined custom concurrency limits and deadlines for each endpoint to prevent Head-of-Line blocking.

4. Smart Deadline Management ⏳

gRPC excels at propagating deadlines. If a client is restless, our server checks at every step: Do I still have time to run this SQL or Druid query? If the deadline has passed, it stops immediately, saving precious compute resources.

⚖️ The Tradeoffs: gRPC vs. REST

We compared our new gRPC service against our legacy REST application. Here is what we found:

Feature Winner Why?
Performance 🏆 gRPC Binary encoding and streaming are simply faster.
Connection Management 🏆 gRPC HTTP/2 multiplexing reduces TCP overhead.
Reliability 🏆 gRPC Strongly typed contracts eliminate runtime validation errors.
Ease of Debugging 🏆 REST REST is human-readable; gRPC requires tools like gRPCurl or BloomRPC.
Browser Support 🏆 REST gRPC requires a gateway/proxy for UI integration.
Infrastructure 🏆 REST Kubernetes liveness probes and API gateways are more mature for REST.

🚀 The Impact: By the Numbers

The transition to gRPC delivered staggering improvements:

  • 39% smaller payloads compared to JSON.
  • 72% less network bandwidth usage (reducing 2.8GB of traffic to 82MB for 1,000 users). 🌐
  • 37% faster response times, dropping from 3,000ms to 1,880ms.
  • 5x less server memory consumption.
  • 4x faster user experience. 🏎️

⚠️ Challenges Along the Way

It wasn’t all smooth sailing. We faced:

  • Learning Curve: Developers had to master Protobuf syntax and streaming semantics.
  • Tooling: We had to adopt new tools like Postman gRPC and BloomRPC for debugging.
  • UI Constraints: The necessity of a routing layer to convert gRPC to REST for the browser.

🎯 Conclusion

The magic formula of Binary Encoding + Streaming + HTTP/2 has made our architecture leaner, faster, and more scalable. While REST makes API calls simple, gRPC makes them fast and efficient.

If you are dealing with high-throughput, low-latency requirements, it is time to give gRPC a serious look.

Q&A Session: The speakers concluded by inviting the audience to connect on LinkedIn for further deep dives into their architectural journey and to address specific implementation doubts. 🤝

#gRPC #Microservices #AdTech #SystemDesign #PerformanceOptimization #TechBlog

Appendix