Yupeng Ma
← Back to projects

Case study · ByteDance · 2022-01 — 2023-11

CDN Vendor Allocation

Traffic allocation across CDN vendors using forecast and performance signals.

Role · Python / Go engineer

  • Go
  • Python
  • CDN
  • RBAC
  • Multi-tenancy
Planning inputs enter an allocation engine, which supports traffic decisions across multiple vendors while monitoring provides operational feedback.

  1. 01

    Overview

    Context
    Video products depended on multiple CDN providers and needed structured procurement, reporting, incident, and allocation workflows.
    My contribution
    Developed workflow features, implemented allocation logic, and extended RBAC multi-tenancy.
    Technology
    Go, Python, CDN systems, RBAC, and multi-tenant backend services.
    Result
    Supported quarterly procurement allocation across multiple CDN providers.

  2. 02

    The Problem

    Quarterly traffic allocation had to account for forecast demand and vendor performance while fitting existing multi-tenant operational and procurement workflows.

  3. 03

    My Role

    Python / Go engineer

    • Developed backend features across the Go-based CDN vendor management workflow.
    • Implemented a traffic-allocation algorithm for quarterly procurement planning.
    • Extended RBAC multi-tenancy for an in-house CDN.

  4. 04

    Architecture

    A focused map of the components and responsibility boundaries that matter to this project.

    Architecture

    Allocation and operations boundaries

    1. 01Planning inputs

      Forecast demand and performance context

    2. 02Vendor workflow

      Planning, reporting, and operations

    3. 03Allocation engine

      Quarterly decision support

    4. 04Procurement plan

      Reviewed vendor allocation

    5. 05Vendor destinations

      Multiple CDN providers

    6. 06Access boundary

      RBAC multi-tenant controls

    7. 07Monitoring

      Operational and performance context

    • Planning inputsVendor workflowcontext
    • Vendor workflowAllocation engineplan
    • Allocation engineProcurement planpropose
    • Procurement planVendor destinationsallocate
    • Access boundaryVendor workflowauthorize
    • Vendor destinationsMonitoringobserve
    • MonitoringVendor workflowfeedback
    Planning inputs enter the vendor management workflow, where allocation logic supports procurement planning across CDN destinations. RBAC constrains tenant access, while monitoring returns operational context to the workflow.

  5. 05

    How It Works

    The primary sequence that moves work or data through the system.

    Flow

    Quarterly allocation workflow

    1. 01Forecast

      Expected traffic demand

    2. 02Performance

      Vendor operating context

    3. 03Allocation

      Quarterly vendor proposal

    4. 04Review

      Operational and procurement review

    5. 05Distribution

      Allocation across CDN vendors

    6. 06Monitoring

      Performance context for future planning

    • ForecastAllocationdemand
    • PerformanceAllocationcontext
    • AllocationReviewpropose
    • ReviewDistributionapprove
    • DistributionMonitoringobserve
    • MonitoringPerformancenext cycle
    Forecast demand and vendor-performance context feed an allocation proposal. The proposal moves through review and procurement planning before traffic is distributed across vendors, with monitoring informing the next planning cycle.

  6. 06

    Key Technical Decisions

    Problem
    An isolated allocation calculation would separate decisions from the workflow and inputs used to operate them.
    Choice
    Keep allocation inside the established vendor management and procurement workflow.
    Why
    This kept forecasts, vendor performance context, operational use, and allocation decisions connected.
    Trade-off
    The allocation implementation had to respect existing workflow boundaries and domain constraints.
    Problem
    The in-house CDN needed tenant-aware access without creating another permissions model.
    Choice
    Extend the existing RBAC multi-tenant model.
    Why
    Reusing the established authorization boundary avoided a parallel access path and kept permissions consistent.
    Trade-off
    New CDN capabilities had to fit the semantics and migration constraints of the existing model.

  7. 07

    Challenges

    • Connecting forecast demand and vendor-performance context to decisions inside an established operational workflow.
    • Extending access controls without fragmenting the multi-tenant authorization model.

  8. 08

    Outcome

    • Supported quarterly procurement allocation for ByteDance video products across multiple CDN providers.
    • Kept allocation decisions, operational workflows, and multi-tenant access controls within one backend system boundary.

  9. 09

    What I Learned

    Learned
    Allocation software is useful only when its inputs, permissions, and operating workflow are understandable to the people using it.
    Reflection
    The system-level story is how allocation decisions stay connected to operational workflows and access boundaries across each planning cycle.

This was an employer-owned production system. Architecture and implementation details shown here are simplified to protect confidential information.