KLS Live Project — Seller Side
Scaled high-value livestream seller operations with batch registration, validation, and monitoring for major campaigns across the region.
- Role
- Backend Engineer (Campaign)
- Timeline
- 2026
- Team
- 4
- Domain
- E-Commerce / Livestream
- Stack
- 10 tech
- Status
- Live
Overview
The KLS Live Project (high-value livestream) was a strategic initiative to grow livestream revenue during major campaigns by improving recruitment, session registration, and operational visibility. I worked as the backend campaign engineer for the seller console side, designing and delivering the backend needed to scale seller participation and go-live readiness across the region.
Gallery
A backend has no screens, so its "UI" is the operational surface: the registration API, the batch/ops flow, and campaign dashboards.
Problem & Solution
The existing process could not comfortably support roughly a 5x increase in eligible sellers, nor lift go-live rates from a low baseline. Registration validation, template-based uploads, batch submission, and go-live tracking all needed stronger backend support to become scalable and observable.
I assessed the end-to-end seller flow and delivered solutions across four repositories: new HTTP/RPC contracts, additional enumeration fields (Estimated Revenue, Expected Ads Spend, platform username, Session Level), multi-region handling, and a new scheduler workflow for batch session registration. I integrated creator validation with shop-channel-service, supported FE testing, absorbed mid-project requirements, and released the seller side with broad self-test coverage.
Workflow
Three actors interact with the service; the diagrams are written in English to stay consistent across both languages.
Architecture
seller-campaign-service accepts uploads and validates rows and creators (via shop-channel-service), then enqueues batches into the scheduler, which registers sessions on the budget-management platform and reports go-live status. campaign-core-service, campaign-registry-service, and campaign-ops-service handle downstream registration and operations. All flows run across multiple regions with Prometheus/Grafana monitoring.
Features
- Online session registration & validation
- Excel template generation & upload
- Go-live status visibility
- Batch session submission via scheduler
- Campaign monitoring across regions
- Multi-region logic
- New scheduler workflow for batch registration
- Creator validation via upstream service
- New API contracts & enum fields
Tech Stack
Engineering Challenges
Participation had to support roughly a 5x increase in eligible sellers reliably. Fix: a scheduler-based batch submission flow with structured validation and upstream creator checks, keeping throughput high without manual bottlenecks.
New fields (e.g. platform username) arrived during development. Fix: adaptable template-generation logic and enum design so the Excel pipeline could absorb changes without rework.
Logic spanned `seller-campaign-service`, `campaign-core-service`, `campaign-registry-service`, and `campaign-ops-service`. Fix: clear ownership boundaries plus broad self-testing across all regions and scenarios.
Outcomes
Lessons Learned
Scaling an operational workflow needs more than new endpoints — it needs careful batch-processing design, clear ownership across repositories, and close alignment with FE, PM, and QA to keep multi-region delivery stable.
Related Santekno Tutorials
Interested in working together?
Order, payment, or high-traffic event pipelines — let's talk architecture and trade-offs.