Self-Service AdTech Platform
Turning a complex enterprise advertising workflow into a guided self-service experience for small merchants — from initial architecture and payments to distributed Redis queues, recoverable state machines, and operational tooling.
Full-Stack Engineer → Team Lead
React · Node.js · MongoDB · Redis · Payments · Enterprise integrations · Analytics · Operations
~20,000 Advertisers at Peak Scale
Production-launched, revenue-generating product
The existing system was built for agencies — not small merchants.
The company already possessed a powerful enterprise advertising engine. But using it required deep domain knowledge: placements, audience demographics, impression targets, creatives, complex billing plans, and fulfilment pipelines.
That complexity worked for professional media agencies. It was completely overwhelming for a small merchant who simply wanted to reach nearby customers.
Hide the complexity of the advertising engine.
The challenge was not to rebuild the ad server from scratch. It was to build a protective anti-corruption translation layer that hid the enterprise machinery.
“Allow a small business to launch a real advertising campaign without needing to understand how the underlying advertising platform worked.”
Simplifying the advertiser journey
We distilled an intricate enterprise media configuration process into a guided 6-step merchant journey:
Authenticate
Instant onboarding and account provisioning with secure session management.
Provide business information
Business details entered manually or retrieved automatically through a live GST API integration.
Choose a target location
The merchant intuitively selects target geographic zones where they want their campaign active.
Understand expected reach
The system dynamically computes and presents forecasted impression volumes based on geometry and budget.
Choose plan & creative template
Pre-approved creative templates and transparent pricing plans eliminate ad spec confusion.
Complete payment & launch or schedule
Direct online checkout. The campaign can launch immediately or wait in pending state for a future scheduled date.
Payment was only the beginning of fulfilment
From the merchant's perspective: Pay → Campaign launches.
Internally, a multi-system orchestration had to succeed across disparate enterprise services:
Payment succeeds, campaign creation fails
The customer has already paid. Asking them to retry checkout would cause double-billing. The backend must record payment and autonomously retry campaign creation.
Campaign created, creative creation fails
A campaign entity exists in the enterprise system, but the ad creative failed. Blindly repeating the entire workflow creates duplicate ghost campaigns.
Downstream enterprise API timeout
A timeout creates uncertainty, not guaranteed failure. The enterprise system may have processed the ad even if our application didn't receive the response.
Application node crashes midway
If a server instance dies mid-orchestration, persisted intermediate state allows other worker nodes to pick up and resume execution exactly where it stopped.
Distributed job processing with Redis & atomic queue pops
Without a dedicated worker fleet, running cron jobs on every instance would cause duplicate processing. We engineered a lightweight coordination architecture using Redis:
┌──────────────────────────┐
│ Designated Cron Node │ (Queries MongoDB for eligible jobs)
└─────────────┬────────────┘
│
Inserts jobs into queue
│
▼
┌──────────────┐
│ Redis Queue │
└──────┬───────┘
│
Publishes work signal
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Node Instance Node Instance Node Instance
│ │ │
└─────── Atomic Queue Pop ────────┘
(First to pop claims work)Redis Pub/Sub (Signalling)
Tells application instances: “Work is available right now.”
Redis List (Work Ownership)
Atomic pop ensures only one instance claims and executes a specific campaign job.
Operational platform & dual-funnel analytics
Production systems require internal tooling to understand and repair state without requiring engineers to touch raw databases:
Built internal operational dashboards for managing plans, ad placements, creative templates, monitoring pending campaigns, and triggering manual recovery on edge cases.
Empowered operations teams to diagnose and resolve campaign states safely, drastically reducing engineering support overhead.
Separated the Product Funnel (acquisition, config, payment conversion via GA/GTM) from the Operational Funnel (payment validated → campaign created → ad associated → fulfilled via MongoDB pipelines).
Recognized that checkout conversion and successful ad delivery are distinct business metrics requiring independent tracking.
Key engineering lessons from 5 years of production
Payment does not equal fulfilment
Checkout completion is only one state transition. When money is involved, the architecture must precisely track and guarantee downstream fulfilment.
Long workflows must expose state
Hiding multi-system asynchronous processes behind a single boolean makes recovery impossible. Explicit intermediate states make retries predictable.
Timeouts mean uncertainty, not failure
A network timeout leaves downstream state ambiguous. Retries must use idempotency keys and downstream identifiers to avoid duplication.
Retries should resume, not restart
If 3 stages succeeded and stage 4 failed, the worker must restart at stage 4 rather than repeating completed enterprise API calls.
Operational tooling is core architecture
Admin dashboards, failure visibility, and reconciliation jobs cannot be afterthought side-features when managing live revenue workflows.
The abstraction is the product
Translating between complex enterprise ad parameters and simple merchant business questions was the true value of the software.
“The difficult part of a distributed workflow isn't making every step succeed. It's designing the system so that when one step doesn't, you still know what happened — and what should happen next.”
The platform grew to serve ~20,000 advertisers, generating significant revenue while proving that thoughtful orchestration, recoverable state machines, and operational tooling make enterprise systems reliable in production.
Building complex enterprise workflows or distributed systems?
I’m open to discussing enterprise platform integrations, asynchronous workflow orchestration, payment reliability, and developer tooling.