1. Why Internet Advertising Is a Typical Systems Engineering Challenge

Internet advertising typically refers to commercial advertising that promotes products or services directly or indirectly through websites, web pages, applications, and other internet media, using formats such as text, images, audio, and video. From a market perspective, internet advertising has become a dominant force in the advertising industry. Its revenue has continued to grow at double-digit year-over-year rates in recent years, its share of overall advertising revenue keeps rising, and in some statistical scopes it even accounts for the vast majority of advertising delivery revenue.

Behind this scale are extreme engineering constraints. A single ad impression may require request parsing, user understanding, candidate retrieval, model scoring, real-time bidding, and creative rendering within a few hundred milliseconds. The system must support hundreds of thousands or even higher requests per second, return results within an extremely tight time budget, and ensure accurate billing, measurable performance, and compliant delivery. This makes internet advertising a typical scenario where high-concurrency architecture, real-time computing, and machine learning engineering intersect.

2. Overall Structure of the Advertising Delivery Pipeline

A mature internet advertising system can usually be divided into the following layers:

• Traffic access layer: Handles ad requests from different media, such as web pages and applications, and completes authentication, rate limiting, protocol adaptation, and traffic cleaning.
• Advertising decision layer: Contains the core logic for retrieval, coarse ranking, fine ranking, bidding, and frequency control.
• Data and feature layer: Provides user profiles, contextual features, ad library features, and real-time behavior sequences for decision-making.
• Performance measurement layer: Handles impression, click, and conversion tracking, deduplication, attribution, and reporting.
• Operations and configuration layer: Manages ad campaigns, budgets, targeting conditions, and creative assets, and delivers them to the system.

These layers are decoupled through clear interface contracts. Message queues are commonly used for asynchronous decoupling and peak shaving. Object storage and cache services carry creative assets, features, and configuration data. Container platforms support elastic scaling of each service.

3. Core Engineering Constraints of Real-Time Bidding (RTB)

Programmatic advertising centers on real-time bidding. When a user request carries an ad slot, the supply side packages this impression opportunity into a bid request and distributes it to multiple demand sides. Each demand side evaluates within a very short period whether to bid and how much to bid. The supply side selects a winner through an auction mechanism and displays its ad.

This process is extremely latency-sensitive. The time budget for the entire path is often only around 100 milliseconds, and the time left for a demand side to fetch features, run model inference, and make a bid decision may be only tens of milliseconds. Therefore, it is necessary to:

• Fetch features locally: Place frequently accessed user and ad features in in-memory cache or low-latency storage to avoid jitter caused by remote calls.
• Use lightweight model inference: Online scoring models must balance accuracy and latency, often using distillation, quantization, and feature pruning to control single-inference cost.
• Apply timeout degradation: Set strict timeouts and circuit breakers for each downstream dependency, and use fallback strategies after timeouts to avoid dragging down the whole pipeline.

A simplified bid decision pseudocode is as follows:

def decide_bid(request, context):
    # 1. Feature assembly (prefer local cache hits)
    user_feat = feature_cache.get_user(request.user_id) or default_user_feat
    ad_feat = feature_cache.get_ad(request.ad_slot_id)
    # 2. Targeting and budget validation
    if not match_targeting(request, ad_feat):
        return no_bid()
    if not budget_available(request.advertiser_id, request.timestamp):
        return no_bid()
    if is_over_frequency(request.user_id, request.advertiser_id):
        return no_bid()
    # 3. Model scoring (predict CTR/CVR)
    pctr = rank_model.predict(user_feat, ad_feat, context)
    # 4. Bid calculation (value = pctr * target bid)
    bid_price = pctr * ad_feat.target_cpi
    # 5. Auction settlement and winning probability are omitted here
    return make_bid(bid_price)

4. Layered Design of Retrieval, Coarse Ranking, and Fine Ranking

Faced with massive ad candidates, directly fine-scoring all ads within milliseconds is unrealistic. The industry commonly uses a funnel-style layered filtering approach:

• Retrieval: Quickly filters hundreds or thousands of candidates from an ad library of millions, based on targeting conditions, user interests, and collaborative relationships. It emphasizes high coverage and low latency.
• Coarse ranking: Uses a lightweight model to perform preliminary scoring on retrieval results, reducing them to tens or hundreds of candidates.
• Fine ranking: Uses more complex models to accurately predict click-through rate, conversion rate, and other metrics, producing the final ranking.

The core idea of this layered design is “finer and more precise toward the end, faster toward the beginning.” Each layer must strictly control latency and candidate scale, keeping overall latency manageable while improving matching quality as much as possible under limited compute resources.

5. Budget Pacing and Frequency Capping: Making Delivery Controllable

Advertisers care not only about whether delivery happens, but also about whether the budget is reasonably spent. If the system quickly exhausts the budget during traffic peaks, subsequent high-value traffic may have no ads to deliver. Therefore, a budget pacing strategy is needed to keep spending as evenly distributed over time as possible.

A common approach is to dynamically adjust the bid multiplier based on planned spend progress and actual spend:

def pacing_factor(plan, now):
    # Plan: total budget B, delivery period [start, end]
    elapsed_ratio = (now - plan.start) / (plan.end - plan.start)
    expected_spend = plan.budget * elapsed_ratio
    actual_spend = plan.spent
    # Raise the bid if spending is behind; lower it if spending is too fast
    gap = expected_spend - actual_spend
    factor = 1.0 + clamp(gap / plan.budget, -0.3, 0.3)
    return factor

Frequency capping is used to limit the number of impressions shown to the same user for the same advertiser. It improves user experience and avoids ineffective spending. These counters require low-latency reads and writes at massive user scale, usually relying on high-performance cache and near-line computation.

6. Performance Measurement: Tracking, Deduplication, and Attribution

The commercial value of advertising ultimately depends on quantifiable performance. The engineering difficulty of measurement lies in collecting, cleaning, and attributing massive tracking events:

• Impression and click deduplication: The same impression may generate duplicate reports due to network retries or page refreshes. Unique identifiers and deduplication windows are needed to remove noise.
• Attribution logic: Conversions often occur within a relatively long window after a click. It is necessary to define attribution windows and attribution models, such as last-click attribution, to correctly associate conversions with ad touchpoints.
• Data pipelines: Tracking data enters a stream processing pipeline after collection, supporting real-time metric calculation and offline detail archiving for real-time monitoring and deep analysis.

At this layer, the coordination of log services, stream computing, and object storage is particularly important. The real-time path handles minute-level metrics, while the offline path handles large-scale backfill and reporting. Together they form a closed loop from data collection to business decision-making.

7. Engineering Design for Compliance and Risk Control

Ad delivery is not purely a technical problem; it is also subject to regulatory constraints. In many jurisdictions, rules for internet advertising impose clear requirements on ad identifiability, explicit labeling as “advertisement,” closure options, pop-ups, and splash ads. These requirements directly affect system design:

• Identifiability labels: During creative rendering, labels such as “advertisement” must be enforced. The system should perform unified checks during delivery to avoid omissions.
• One-click close and countdown: For splash and pop-up ads, compliant closure capabilities and necessary display-duration controls should be provided.
• Content review pipeline: Before delivery, ads should pass qualification checks and creative review, with traceable review records to intercept non-compliant content.
• Data compliance: The use of user features and profiles should follow principles such as minimum necessity and consent-based authorization. Sensitive data should be masked and protected by access controls.

Making compliance a system capability rather than an after-the-fact patch is the baseline for sustainable operation of an advertising platform.

8. Stability, Observability, and Elasticity

Facing traffic peaks caused by major promotions and hot events, advertising systems must have strong stability:

• Layered rate limiting and degradation: Rate limits should be set at both the traffic access layer and the decision layer. When overloaded, core paths should be prioritized and non-core strategies degraded.
• Full-chain observability: A unified logging, monitoring, and alerting system should cover request volume, latency percentiles, bid win rate, budget consumption, error rate, and other key metrics.
• Elastic scaling: Container platforms can automatically scale compute resources with traffic changes, balancing cost and capacity.
• Capacity stress testing: Full-chain stress tests should be conducted regularly to verify system behavior under peak traffic and identify bottlenecks in advance.

9. Summary

The technical essence of internet advertising is to connect real-time bidding, precise matching, performance attribution, and compliance/risk control into a stable and efficient pipeline under extreme latency and large-scale constraints. It requires developers to combine distributed systems, real-time computing, and machine learning engineering: use layered architecture to control complexity, use cache and degradation to protect latency, use pacing and frequency capping to make delivery controllable, use rigorous tracking and attribution to make performance measurable, and build compliance into system capabilities. Understanding this methodology enables building high-performance and sustainable advertising delivery platforms for different business scenarios.