Why the Alarmy team built its own SSP

The journey to tens of billions of KRW in monthly ad revenue

"Three days to integrate the AdMob SDK, a week to set up mediation. So why is the eCPM this low?"

Anyone who has tried to monetize app ads has hit this at least once. Integrating countless ad networks one by one, configuring a tangled waterfall, running endless A/B tests to optimize eCPM (revenue per 1,000 impressions). And to optimize revenue in earnest, you eventually have to build your own ad server. For most development teams, that's close to an impossible mission.

Our team faced the same problem, running tens of billions of KRW in monthly ad revenue while operating Alarmy, the world's number one alarm app. We poured all the know-how and technology we accumulated into one integrated solution, Daro. Today we'll talk about one part of it: the SSP (supply-side platform). This post looks at how Daro's SSP implements the OpenRTB protocol, and the architecture it actually uses to maximize revenue.

‍

Why do you need an SSP?

The evolution of programmatic advertising

To understand why an SSP matters, you have to look at how programmatic advertising evolved. Remember the early 2000s, when publishers negotiated with advertisers one at a time? Each campaign negotiation took weeks, and a large share of inventory went unsold. An inefficient era.

RTB (real-time bidding) arrived in 2009 and changed everything. A live auction completes within a few hundred milliseconds, and as of 2025 most digital ad spend worldwide is traded programmatically.

‍

What the SSP does

The SSP is the core infrastructure behind this shift.

The SSP's core value isn't simply connecting many advertisers. It provides the technical infrastructure that integrates directly with many DSPs (demand-side platforms) and puts each of a publisher's ad placements up for auction in real time.

A developer contracting individually with dozens of DSPs, integrating each SDK, and implementing the OpenRTB protocol? That's not realistic. The SSP solves all of that complexity behind one integrated interface.

‍

Three practical reasons it's hard to build your own SSP

"If it's that good, why not just build our own SSP?" You might think that. Reality isn't so forgiving.

First, the technical bar is steep.

• Building data centers distributed worldwide
• Sustaining 99.99% uptime
• Fully implementing the OpenRTB protocol
• Optimizing through real-time data analysis

Second, operating costs are substantial. Even a small or mid-sized ad-tech company spends billions of KRW a year on infrastructure. Large platforms are on a far bigger scale.

Third, economies of scale are at work. DSPs are reluctant to integrate with an SSP that lacks enough traffic. Some of Daro's DSP partners required a minimum of 1 billion bid requests a day. It's a chicken-and-egg problem.

An SSP is a matter of partnership more than construction. That's why you need a proven solution like Daro. Let's look at how an SSP actually works, starting with its core, the OpenRTB protocol.

‍

OpenRTB: the standard protocol for global ad trading

What is OpenRTB?

For an SSP and a DSP to communicate, they need a common language. That language is OpenRTB (Open Real-Time Bidding).

How does this protocol, established by the IAB Tech Lab in 2010, work? Let's look at a real example.

‍

The data structure

OpenRTB's core is a carefully designed data structure.

A Bid Request is a JSON object describing an ad opportunity, built from nested structures: Impression (ad slot info), Site/App (publisher context), Device (device info), User (user data). The DSP analyzes it and has to return a Bid Response in a short time; the industry typically requires a response within a few hundred milliseconds.

OpenRTB also handles every ad format in a standardized way. Banner defines size and position; Video defines playback duration and bitrate per the VAST (Video Ad Serving Template) standard; Native defines individual assets like the title, image, and CTA button. Thanks to this unified structure, a publisher can manage every ad format with one system.

‍

The 100-millisecond war

A user opens the app. The instant an ad slot appears, here's what happens:

1. Generate the Bid Request (10ms)
   - Impression: "banner ad, 320x50 size"
   - Device: "iPhone 14, iOS 17"
   - User: "interests: sports, location: Seoul"

2. Send to DSPs simultaneously (20ms)
   - Parallel requests to 30 DSPs

3. Collect DSP responses (50ms)
   - DSP A: bids ₩100
   - DSP B: bids ₩150
   - DSP C: bids ₩120

4. Auction and ad serving (20ms)
   - Winner: DSP B
   - Render the ad

Total elapsed time: 100 milliseconds.

All of this happens in an instant the user never notices.

‍

The practical difficulty of implementing OpenRTB

The theory looks simple. What about the actual implementation?

First, enormous throughput. A large-scale SSP has to process millions of queries per second. Handling tens of billions of requests a day reliably requires advanced architecture: distributed processing, in-memory caching, asynchronous message processing.

Second, extreme speed demands. Factor in network latency and the real processing time gets even shorter. Connection reuse, data compression, parallel processing: you have to save milliseconds at every stage.

Third, security and policy compliance.

• HTTPS/TLS 1.2+ encryption
• sellers.json / ads.txt policy compliance
• GDPR/CCPA consent handling

You have to satisfy all of this at once.

Daro's OpenRTB implementation reliably handles millisecond-level auctions through auto-scaling on cloud infrastructure, intelligent traffic routing, and real-time performance monitoring. Instead of implementing a complex protocol, a developer gets immediate access to the global programmatic ecosystem with a single SDK integration.

OpenRTB is more than a technical standard. It's the foundation of the fast-growing programmatic ad market. Now let's look concretely at how Daro implemented this standard, through its actual system architecture.

‍

How was the Daro SSP built?

The tech stack we chose

The thing that mattered most in building the Daro SSP was technology proven in production.

Why we chose Go + Fiber v3

• Go's lightweight goroutines: handling tens of thousands of concurrent connections
• Fiber v3's zero memory allocation: extreme performance optimization

On that base, we built a high-performance system that reliably handles high-volume bid requests.

Dual support for OpenRTB 2.x/3.x

We kept compatibility with legacy DSPs while making the most of the latest standard's advantages. That maximized the demand sources we can reach.

‍

The core of real-time bidding: orchestration

Processing fast isn't the whole job.

The real challenge of real-time bidding is orchestration, not plain parallel processing. Daro adjusts, in real time, the different response speeds, protocol versions, and data formats of dozens of DSPs, converging them into a single auction. It finds the balance point, not waiting on the slowest DSP, yet not missing the highest bid, and completes the whole auction within a few hundred milliseconds.

‍

An extensible architecture

We designed it following DDD (domain-driven design) principles.

AdUnit
  ├── Encapsulates its own business rules
  └── Independent domain entity
Bidder
  ├── Per-DSP protocol implementation
  └── Unified behind a single interface
Publisher
  ├── Revenue optimization logic
  └── Floor price management

'When you add a new DSP, you only implement the interface, with no impact on the existing system. Major DSPs at home and abroad are already integrated stably on this structure, and partners keep getting added quickly.

This structure isn't there for technical elegance alone. The ad-tech market changes fast, and new ad formats, protocols, and DSPs can keep appearing. Daro's domain-driven modular structure is the foundation for responding to that change with agility.

‍

The core of data-driven optimization: the event analysis system

Every bidding event each auction generates, from BidRequest through Click, is streamed in real time through Kafka. This data, piling up at tens of billions of records a day, is analyzed in ClickHouse to produce smarter revenue optimization strategies.

Alongside this, support for the Win Notice URL (NURL) and Loss Notice URL (LURL) achieves transparency and optimization at the same time. A DSP can learn why its bid lost, and Daro analyzes that data to adjust the floor price. For example, if bid competition is fierce in a given time window, it raises the floor price to maximize revenue; in low-competition windows, it lowers the floor price to raise the fill rate.

‍

Beyond the technology: proven monetization know-how

This post looked at how the Daro SSP implemented OpenRTB, and the technical challenges it solved as it grew.

But Daro's real value isn't in the technical infrastructure alone. The Alarmy team's know-how, accumulated by running tens of billions of KRW in monthly ad revenue directly, is built into the system everywhere.

Which time windows to adjust the floor price in to maximize revenue. How to respond when a particular DSP's responses slow down. Where the optimal balance between fill rate and eCPM sits. The answers to questions like these come not from documentation or theory, but only from years of hands-on experience.

In other words, choosing Daro isn't simply adopting an SSP. It means applying directly to your app the trial and error the Alarmy team went through building billions of KRW in revenue, the optimization know-how found along the way, and the operational strategy still improving every day.

You can integrate all of it in three days with a single SDK.

Stop wrestling with complex ad technology. Let developers focus on building a better app, and leave ad monetization to Daro, which has already walked that road.

With Daro, your app can be the one earning tens of billions of KRW a month too.

‍