Full-stack engineering for a digital advertising platform handling millions of ad requests - real-time bidding infrastructure, analytics and scale.
act.ad is a digital advertising platform that connects advertisers with publishers through programmatic buying. The platform needed to scale from handling tens of thousands of ad requests per day to millions - while maintaining the sub-100ms response times that real-time bidding requires.
Silkate took on full-stack engineering responsibility: rebuilding the bidding infrastructure, redesigning the analytics pipeline and delivering a new publisher-facing dashboard.
Real-time bidding engine (Koa)
The previous bidding system was a monolithic service that couldn't handle concurrent auction load without degrading response times. We rebuilt it as a stateless bidding service using Koa with worker threads for CPU-bound bid evaluation, backed by Redis for campaign budget caching and rate limiting.
The new engine processes auction requests through a pipeline:
Response time at peak load dropped from ~340ms to under 60ms.
Analytics pipeline
Ad event data (impressions, clicks, conversions) previously flowed directly into a PostgreSQL database on each request - fine at low volume, catastrophic under load. We replaced this with an event queue-based approach: events write to a Redis stream, a consumer group drains them in batches to the database and a second consumer feeds a ClickHouse instance for real-time reporting queries.
This decoupled event ingestion from database write pressure, eliminating the latency spikes that had been corrupting bid response times during reporting-heavy periods.
Publisher dashboard (SolidJS / TailwindCSS)
Built a new publisher-facing dashboard with real-time performance metrics (impressions, fill rate, eCPM), campaign management controls and a payout history view. The dashboard pulls live data through a lightweight WebSocket feed connected to the analytics pipeline. SolidJS's fine-grained reactivity meant individual metric nodes update in place without full component re-renders, keeping the UI responsive under high data velocity.
Particular attention was given to the metric display cadence - we debounced WebSocket updates to prevent the dashboard from refreshing faster than users could read it, while keeping numbers within 3 seconds of real time.
We evaluated using Kafka for the event queue but selected Redis Streams for this deployment. The operational overhead of running a Kafka cluster wasn't justified at the current event volume (~4M events/day) and Redis was already in the stack for bid caching. The architecture was designed to migrate to Kafka if volume grows by an order of magnitude.
ClickHouse was selected specifically for the reporting use case. The aggregation queries required for publisher reporting (group by campaign, publisher, time bucket, with filtering) perform significantly better on a columnar store than on PostgreSQL at the volumes involved.
The platform now handles sustained load of 3-4M ad requests per day with p95 bid response times under 80ms. Fill rate improved by 14% (partially attributable to faster bid responses making the platform more competitive in real-time auctions). The publisher dashboard reduced support ticket volume around payout queries by roughly 60%, as publishers could self-serve the information they previously contacted support to obtain.