Employer-owned production system · ByteDance · 2022–2023
CDN Vendor Management & Capacity Allocation
Monthly procurement planning across domestic CDN vendors for large-scale video delivery.
I extended an existing vendor management platform, with capacity allocation as my main contribution alongside RBAC and business-facing data APIs.
MONTHLY PLANNING
→ Vendor procurement quantities
01 / Context
What system did I work on?
I worked on an existing internal platform for managing domestic CDN vendors used by ByteDance's large-scale video products. The platform was already in production before I joined; I did not design it from scratch.
My work was incremental production engineering inside that system. The most interesting contribution was a monthly capacity-allocation capability, supported by permission work, data aggregation APIs, and other evolving business logic.
Read the diagram description
The diagram places the existing CDN vendor management platform in the background rather than claiming it was created from scratch. A monthly capacity plan and domestic vendor profiles enter the allocation logic. Vendor profiles contribute a capacity ceiling, objective quality signals, and subjective evaluation. A separate diversification policy limits concentration risk. The allocation logic combines hard constraints, soft preferences, and risk rules to produce procurement quantities for abstract vendors, then hands those quantities to the platform's downstream issue and delivery boundary. The diagram intentionally contains no real vendor names, values, weights, prices, billing units, internal topology, or live request routing.
02 / Business context
Why plan CDN capacity before each month?
Large-scale video delivery depends on external CDN vendors having enough service capacity available. Before each monthly cycle, the business needed to decide how much capacity to procure from each domestic provider and issue that plan downstream.
This case study describes capacity procurement without claiming whether an internal contract settled by traffic, peak bandwidth, 95th-percentile bandwidth, or another commercial unit.
03 / Ownership
What did I contribute?
I implemented the monthly vendor-capacity allocation logic and developed parts of the role-based access model. I also delivered backend APIs that assembled operational views from existing business data.
A meaningful share of the work was ordinary production backend development: SQL aggregation, joining information from different parts of the system, encoding changing rules, and returning stable data to the frontend.
CONTRIBUTION SURFACE
One focused capability, plus the work around it
- Capacity allocationMonthly procurement quantities across domestic CDN vendors
- RBAC extensionsRole-aware access inside the existing platform
- Data aggregation APIsMySQL aggregation and cross-source assembly for frontend views
- Business workflowsOngoing backend changes as operational requirements evolved
04 / Engineering
What made allocation difficult?
No individual API or query was unusually difficult. The challenge was turning several business policies—some hard, some preferential, and some risk-driven—into one maintainable allocation result.
Those policies could pull in different directions. The implementation needed to preserve firm limits while still expressing quality preferences and avoiding excessive dependence on one supplier.
The hard part was translating competing business policies into explainable allocation logic.
05 / Rules
What constraints had to hold?
Each vendor had a ceiling on the CDN capacity it could provide, so its assigned quantity had to remain below that limit. Together, vendor quantities also had to cover the capacity planned for the monthly cycle.
The public explanation stays at the level of constraint categories. It does not disclose real vendors, capacities, weights, prices, thresholds, or internal decision rules.
DECISION MODEL
Hard limits, preferences, and concentration risk
- 01 · Hard constraintVendor capacity ceilingA vendor's allocation stays below the capacity it can provide
- 02 · Hard constraintPlanned capacity coverageCombined quantities cover the monthly procurement plan
- 03 · Soft preferenceQuality preferenceObjective signals and subjective assessment favor stronger service
- 04 · Risk constraintSupplier diversificationAvoid excessive dependence on one dominant provider
The public case study explains categories of policy—not confidential values, weights, prices, vendors, or thresholds.
06 / Quality
How did quality affect allocation?
CDN quality was judged across several dimensions. Some signals were objective measurements; others came from subjective business assessment.
Higher-quality vendors should generally receive more capacity, but quality was a preference rather than the only rule. Capacity ceilings and portfolio-level risk still constrained the final result.
07 / Risk
Why not give everything to the best vendor?
Concentrating procurement with one dominant provider would increase dependency and weaken the buyer's position. A locally optimal quality choice could therefore create an undesirable portfolio-level risk.
The allocation logic preserved supplier diversity instead of putting every egg in one basket.
08 / Integration
How did this fit into the existing platform?
The capability read vendor and planning data already maintained by the platform, applied allocation rules, produced monthly procurement quantities, and passed the result into the platform's downstream issue boundary.
Around that path, RBAC changes controlled who could use business capabilities, while MySQL aggregation and cross-source assembly supported the operational views consumed by the frontend. This was not a live traffic router.
MONTHLY PROCESS
Allocation stayed inside an existing platform boundary
- 01Existing platform dataVendor and business context
- 02Monthly capacity planQuantity to distribute
- 03Allocation rulesLimits, quality, diversity
- 04Vendor quantitiesMonthly procurement result
- 05Downstream issuePlatform delivery boundary
This is procurement-capacity planning. It does not represent live request routing or a confirmed billing unit.
09 / Reflection
What did I learn from this kind of backend work?
Production backend engineering is not always about inventing a new architecture. Much of its value comes from understanding an existing system and translating changing business policy into reliable, reviewable changes while keeping permissions, data, and existing behavior consistent.
What I would still defend is the discipline of separating hard constraints, preferences, and risk rules. That makes ordinary business logic easier to reason about without pretending it is more exotic than it is.
This was an employer-owned production system. Architecture and implementation details shown here are simplified to protect confidential information.