hoichoiBengali stories, streamed to a hundred countries.
The backends and editorial tools that moved a paying Bengali streaming service off a rented platform — 40 million user records, without the audience noticing.
- Role
- Full-stack engineer · led CMS frontend
- Timeline
- Oct 2023 → 2025 · platform migration
- Team
- Engineering squad with hoichoi product, DevOps, QA and content ops
- Focus
- Backend, CMS and data migration for the largest Bengali OTT platform as it left its SaaS stack
- Live
- hoichoi.tv
- Stack
- NestJS·GraphQL·MongoDB·Redis·React·Next.js·AWS ECS·RDS·CloudFront·CloudWatch + X-Ray·Cloudflare
- of daily users served by the backends
- Millions
- requests per hourGRAPHQL + REST ON MONGODB
- 10M+
- user records migrated99.9% UPTIME, ZERO CRITICAL DOWNTIME
- 40M
- CloudWatch spend$10K → $3K A MONTH
- −70%
Leaving the vendor without the audience noticing.
hoichoi launched in 2017 on a licensed OTT platform. By the time the catalogue passed 800 films and 200 originals, with a paying audience spread across Kolkata, Dhaka, London and New Jersey, the vendor stack had become the ceiling: every meaningful change was a negotiation over timelines, limits and dependencies.
Leaving meant rebuilding the parts nobody sees: the catalogue and subscriber backends serving millions of daily users, the editorial tools that put a new episode on the home page every Friday, and a data model that had grown by accretion for eight years. All of it had to move without the audience noticing.
And it had to stay profitable. hoichoi is one of the few Indian OTT services that runs without burning cash, so the new platform's cloud bill was a product requirement, not an afterthought.
Every rail, title and plan below is served by the backends I built.
CMS lead, backend builder, migration owner.
I joined the squad building hoichoi's in-house platform. I led frontend development of the content CMS and built NestJS services behind GraphQL and REST APIs on MongoDB, the layer that serves catalogue, subscriber and playback metadata to the apps.
I owned the migration of 40 million user records and 10,000+ movies and series onto the new schema, extracted SMS and email into asynchronous microservices, and ran the observability cost work that cut CloudWatch spend by 70% without losing signal.
Not mine: the video player and the native apps. I built what feeds them.
Backend
- NestJS services, GraphQL + REST
- MongoDB with TypeORM
- Redis caching
- Async microservices for SMS and email
CMS
- React/Next.js editorial console
- Catalogue, scheduling, rails, metadata
- Role-based publishing workflows
- Bulk operations and previews
Data
- 40M user records migrated
- 10K+ movies and series re-modelled
- Dual-write, backfill, verify, cut over
- 99.9% uptime through the move
Cloud
- AWS ECS/EC2, RDS, S3, CloudFront
- CloudWatch + X-Ray, spend cut 70%
- CI/CD on GitHub Actions
- Cloudflare at the edge
A GraphQL gateway, NestJS services, and a CMS that writes through them.
Apps and web talk to a GraphQL gateway in front of NestJS services on MongoDB. Editors work in a React CMS that writes through the same services. Side effects that used to block requests, SMS and email, run as queue-fed microservices. Everything is on AWS behind Cloudflare, with CloudWatch and X-Ray tuned to what operations actually look at.
- 01
Dual-write
New writes land in both schemas behind a flag.
- 02
Backfill
Idempotent batches with checkpoints walk the old store.
- 03
Verify
Counts and sampled records diff to zero before anyone flips anything.
- 04
Cut over
Reads switch per domain, with a tested rollback path.
- 05
Decommission
The vendor store goes read-only, then dark.
- 01
Clients
- Web, Android, iOS, TV apps
- GraphQL for reads
- REST for provider callbacks
- Edge caching via Cloudflare
- 02
Services
- NestJS modules per domain
- Catalogue, subscribers, entitlements
- TypeORM on MongoDB
- Redis for hot reads
- 03
CMS
- React editorial console
- Workflows and permissions
- Rails, scheduling, metadata
- Publishing time halved
- 04
Async
- SMS and email microservices
- Queues with retries and DLQ
- Idempotent handlers
- 30% less core load
- 05
Operations
- ECS/EC2, RDS, S3, CloudFront
- CloudWatch metric filters
- X-Ray tracing
- GitHub Actions CI/CD
Forty million users, ten million requests, one bill.
- CHALLENGE 01
Moving 40 million users without a maintenance page
The old and new platforms had to serve the same subscribers at the same time until the last one had moved.
The migration ran as dual-write, backfill, verify, cut over. New writes landed in both schemas, a backfill walked the old store in idempotent batches with checkpoints, and a verifier compared counts and sampled records until the diff was zero. Cut-over flipped reads per domain behind a flag with a tested rollback path. 40M user records and 10K+ titles moved with 99.9% uptime and no critical downtime.
- CHALLENGE 02
Ten million requests an hour on a document database
MongoDB is fast when the schema matches the read path and painful when it doesn't.
The new schema was designed from the queries backwards: rails and title pages read from pre-shaped documents, GraphQL resolvers batch with dataloaders to kill N+1s, hot reads sit in Redis, and indexes were cut to the ones the profiler could justify. The result serves millions of daily users and 10M+ requests an hour with headroom.
- CHALLENGE 03
A CMS editors do not fight
Friday drops are decided by how fast a small editorial team can publish, schedule and fix metadata.
I led the CMS frontend: role-based workflows, bulk operations, previews of rails as viewers will see them, and validation that catches broken metadata before it reaches the home page. Publishing time fell by half, and the team stopped keeping a spreadsheet next to the tool.
- CHALLENGE 04
Observability that does not eat the margin
The first CloudWatch bill on the new platform was $10K a month, mostly for metrics nobody looked at.
Metric optimisation (custom metrics collapsed into dimensions that matter), selective logging with levels per service, log retention tuned per stream, and query tuning on the dashboards operations actually open. Spend fell to $3K a month with no loss of alerting coverage, and X-Ray traces still follow a request across services when something breaks.
- metric filters
- log levels + retention
- query tuning
10M+ requests an hour looks like this
0requests served since you opened this section
From the editor's screen to the database.
- 01
Content CMS
Editorial console for catalogue, rails, scheduling and metadata with role-based workflows, bulk ops and previews. Publishing time cut 50%.
- 02
Catalogue and subscriber services
NestJS + GraphQL/REST on MongoDB and TypeORM serving millions of daily users and 10M+ requests an hour.
- 03
Migration tooling
Dual-write, checkpointed backfill, verifier and per-domain cut-over for 40M users and 10K+ titles.
- 04
Notification microservices
SMS and email extracted from the core into queue-fed services with retries, idempotency and dead-letter handling; core load down 30%.
- 05
Observability and cost
CloudWatch metric, logging and query tuning that cut spend 70%, plus X-Ray tracing across services.
- 06
Release readiness
Load checks and runbooks for Friday drops on the new platform.
Plans and entitlements, served by the subscriber services PLANS AND ENTITLEMENTS, SERVED BY THE SUBSCRIBER SERVICES 
The same entitlement API on a phone THE SAME ENTITLEMENT API ON A PHONE 
Catalogue rails: pre-shaped documents, one read per rail CATALOGUE RAILS: PRE-SHAPED DOCUMENTS, ONE READ PER RAIL 
The free tier, gated by the same subscriber services THE FREE TIER, GATED BY THE SAME SUBSCRIBER SERVICES
Owned end to end, twice as fast to publish, 70% cheaper to watch.
hoichoi now owns its stack end to end. Changes that used to be planned in weeks can be tried in days, editors publish twice as fast, and the platform serves a global Bengali audience at a cost the business can sustain.
- Millions of daily users and 10M+ requests an hour served from the in-house backends
- 40M user records and 10K+ titles migrated at 99.9% uptime with zero critical downtime
- Editorial publishing time down 50%; SMS and email off the critical path, core load down 30%
- CloudWatch spend down 70% ($10K to $3K a month) with alerting coverage intact
- Weekly originals and Friday drops now ship on a platform the team controls
“A lot of the things we used to plan in weeks can be tried in days.”HOICHOI PRODUCT OPERATIONS, ON THE MIGRATION (PUBLIC POST, 2026)