Target Budget Pool Phase 2 — Special Approval
Built a backend approval-exemption module for fine-grained budget control over over-subsidized sellers and creators.
- Role
- Backend Engineer (POC)
- Timeline
- 2026
- Team
- 3
- Domain
- E-Commerce / Budget & Finance
- Stack
- 8 tech
- Status
- Live
Overview
Target Budget Pool Phase 2 introduced finer-grained cost control at the seller/creator object level, complementing the existing department-level budget pool. I owned the Special Approval Exemption module, which lets downstream teams request temporary exemptions when over-subsidized merchants or creators need to be excluded from strong-control blocking.
Gallery
A backend has no screens, so its "UI" is the operational surface: the approval API, the exemption/ops flow, and the approval-workflow callback path.
Problem & Solution
The prior budget-control setup lacked a structured online mechanism for special exemption cases. Without it, teams could not consistently apply, approve, track, or enforce exemptions — making cost governance harder and risking blocking of legitimate campaign scenarios.
I designed the module end-to-end: a normalized database schema (4 RDS tables optimized for up to 1,000 targets and 1,000 budget bills per application), 5 HTTP endpoints with matching RPC interface contracts, activity flows for all major operations, approval-workflow callback handling for approve/reject, multi-tenancy support, and security approvals for new RPCs. I also ran integration testing with the consumer service and fixed production-readiness issues (panic handling, ID truncation) before release.
Workflow
Three actors interact with the service; the diagrams are written in English to stay consistent across both languages.
Architecture
The service persists applications, records, targets, and budget-bill links across four normalized tables with indexed query patterns (status, effective period, target IDs). Approval requests flow to the approval workflow system, whose callbacks are differentiated from consumer callbacks and then applied as exemptions downstream. Everything runs across multiple regions with Prometheus/Grafana monitoring.
Features
- Request exemptions for over-subsidized targets
- Track approval status end-to-end
- Normalized schema (4 RDS tables)
- 5 HTTP endpoints + matching RPC interface contracts
- Approval-workflow approval / rejection callbacks
- Multi-tenancy
- Security-reviewed RPC interfaces
Tech Stack
Engineering Challenges
The module had to work with the approval workflow system, budget bills, and downstream consumers safely across multiple regions and status transitions. Fix: a normalized schema plus clear separation of consumer vs approval-workflow callbacks.
Callback integration exposed panic errors and ID truncation bugs. Fix: hardened callback differentiation and validation, resolved during joint debugging before release.
Outcomes
Lessons Learned
Governance-heavy modules succeed when data modeling, approval-flow boundaries, and callback semantics are designed together. Early alignment on schema and callback behavior sharply reduced ambiguity during cross-service integration.
Related Santekno Tutorials
Interested in working together?
Order, payment, or high-traffic event pipelines — let's talk architecture and trade-offs.