# Road to Cartcast > At around 200 concurrent viewers on a live show, Vercel serverless function concurrency reached its ceiling. The whole site locked up — 15 to 30 seconds to serve any request. Meanwhile, Supabase was holding 69 of 120 available connections with zero active queries. The database was fine. Source: https://saascode.ai/inside/road-to-cartcast · Published: 2026-08-28 · Section: builds · Product: Cartcast (https://saascode.ai/products/cartcast) --- At around 200 concurrent viewers on a live show, Vercel serverless function concurrency reached its ceiling. The whole site locked up — 15 to 30 seconds to serve any request. Meanwhile, Supabase was holding 69 of 120 available connections with zero active queries. The database was fine. The slowdown was nowhere near the database. That incident, encountered while running a prior live platform of ours, became the specification for Cartcast's real-time architecture. Per-viewer server-sent events — one long-lived connection per watcher — cannot scale on serverless infrastructure. The fix is a shared-cache stable-URL short-poll at the edge: a 3-second TTL the CDN serves from cache to any number of simultaneous viewers. Measured at 418 viewers, the same request that took 7.9 seconds returned in 0.22 seconds. Cartcast is the live-commerce platform we built with that lesson already baked in: live shopping shows, in-stream checkout, and shoppable video replays, delivered to a merchant's own store via a lightweight embed script. ## Starting point Cartcast has a direct predecessor in our catalog: LiveCart, a live-shopping embed built in an earlier iteration of the platform — same product shape, including live shows, in-video checkout, and shoppable replay, but a different generation with no code we could carry forward. The streaming engine that powers Cartcast came from a different prior build, a live-streaming platform for competitive gaming, where 1-to-many RTMP broadcast was already production-proven and where we first learned how serverless concurrency behaves under real viewer load. The starting position was neither a blank sheet nor a rebuild. The broadcast stack, the CDN delivery pattern, and the advisory-lock checkout mechanism had all shipped before. What was genuinely new — and genuinely difficult — was integrating them in a context where each merchant is an isolated tenant, shoppers are anonymous users on a third-party site, and the embed must work on any domain without touching that domain's JavaScript or payment surface. The bet was that the hard part was multi-tenant integration and the anonymous-shopper surface, not the video primitives. That turned out to be correct, with some instructive detours. ## Reading the market Live commerce has scaled in the West primarily as a marketplace format — Whatnot, TikTok Shop — not as an infrastructure layer that brands deploy on their own sites. Cartcast is the inverse of the marketplace model: the audience stays on the merchant's own domain, engaging with the merchant's own catalog, checking out on the merchant's own brand page rather than a shared discovery platform. The market evidence for this brand-site shape is mixed. The category leader, Bambuser, reported declining recurring revenue in its most recent period. Meta exited live shopping; Amazon wound down its own experiment. Cartcast does not assume a rising tide — it is infrastructure for an operator who has already made a judgment about the channel and needs the plumbing to run it. The alternatives that share this same-site-embed shape — Channelize.io (which absorbed LiveScale in late 2025) is the closest analog — price on subscription tiers that climb with usage, or require enterprise arrangements without self-serve entry. The gap Cartcast occupies is a self-serve tier without per-view overages: the platform's streaming cost is CDN bandwidth, which at launch scale is well under a dollar per show. ## The decisions that shaped it **Self-hosted ingest, CDN fan-out.** The central cost insight for 1-to-N live video is that the CDN, not the ingest server, carries the audience. One box running the open-source media server produces a single HLS stream; the CDN fans that out to however many viewers connect. At launch scale this runs around €54 per month for a mid-tier dedicated server plus a fraction of a cent per gigabyte of CDN delivery — under a dollar per show. Per-participant billing models, the default for managed real-time SDKs, price a moderately popular show at a multiple of that. The trade-off is a hard ceiling on simultaneous broadcasters — around 20 to 25 per box — rather than a ceiling on viewers. Horizontal scaling for a multi-tenant operator with many merchants live simultaneously requires adding boxes or moving to a managed ingest service. That territory is unverified. **Real-time engagement as fan-out, not per-viewer connection.** Cartcast's real-time layer uses Supabase Realtime broadcast sub-topics per show — separate topics for chat and product pins — plus a stable-URL edge-cached short-poll as a fallback. Both paths are share-based: one Supabase connection per active show fans out to every viewer subscribed to that topic. Per-viewer server-sent events are prohibited in the architecture. The short-poll endpoint carries a 3-second shared cache header, so a crowd of simultaneous viewers receives the same CDN-cached response rather than each hitting the serverless function individually. **Inventory under flash-offer spikes: Postgres advisory locking.** When a product drops at a specific moment during a live show, many viewers may attempt checkout simultaneously. Cartcast resolves this with a Postgres advisory lock inside a database-level stored procedure — an atomic read-decrement-commit that prevents overselling without a separate cache that can drift from the database. A cart-hold TTL reservation — tentative inventory hold during the checkout window, released after expiry — is a sensible next-version addition. v1 does not include it. **The shopper is anonymous by design.** Viewers who watch and buy go through a viewer-fingerprint token rather than an authenticated account. No login, no email required to check out. The payment widget loads in an iframe on Cartcast's own origin, so payment data never touches the merchant's page or DOM. This is a security architecture decision, not a UX shortcut: it allows a single embed script to work on any merchant's site without requiring the merchant to configure authentication flows for their own customers. **Two Stripe integrations, never merged.** Platform subscriptions — what merchants pay to access Cartcast — and merchant payouts — what Cartcast routes to each merchant's Stripe Connect account after a sale — live in separate webhook handlers. Consolidating them is a tempting simplification that produces silent data corruption when an event is processed by the wrong handler. The handlers are separate by doctrine. Application fees, the platform's commission on each sale at a rate the operator configures, travel as cents at the Stripe API boundary and are converted to dollars before storage. **Product timestamps are database rows; the video file is never touched.** Shoppable VOD is implemented as append-only event records — show identifier, product identifier, event type, and offset in seconds — written during the live session and read by the VOD player as it advances through the recording. Re-editing which products appear at which timestamps requires no re-encoding because the encoding and the product overlay are fully decoupled. A one-hour show is typically shoppable within two to five minutes of ending. **VOD processing runs on the ingest box, not in a serverless function.** Serverless functions carry a 300-second execution cap. Live shows run 30 to 90 minutes. Transcoding a 90-minute recording and packaging it for HLS delivery does not fit inside five minutes. The VOD pipeline dispatches to the ingest server via a durable message queue — the end-of-stream trigger fires a webhook, the queue handles deduplication and retries, and ffmpeg on the ingest server converts and uploads. ## What fought back **The zombie live-row lockout.** When a broadcaster drops an RTMP connection uncleanly — a crash, a power cut, a network failure — the ingest server holds the dead session in its registry for roughly an hour. The database row stays `live`, and the admission logic rejects the host's next publish attempt as `already_live`. The host is locked out of their own show for up to an hour. The obvious fix is a background reaper that detects sessions that look stale and terminates them. That fix is an anti-pattern here: the ingest server flushes its recording buffer to disk only approximately every two minutes, so a healthy stream looks stale by any freshness heuristic for most of its runtime. The reaper would kill live shows. The correct fix is an admission takeover: a new publish from the same merchant supersedes their own stale session, marks the old row ended, and proceeds. That is what shipped. **Nine row-level security policies that failed open.** RLS policies on Cartcast's anonymous-shopper surface — covering live shows, carts, cart items, viewer sessions, chat messages, reactions, order items, video replays, and catalog products — were initially written as `USING (true)`: any anonymous database request could read any row across any tenant. The application layer used a privileged database client that bypassed RLS, so no data escaped during the build, but the anonymous key previously failed open. The fix required scoping each policy to the correct visibility predicate: a live show is readable when its status is `live` or `available`; a cart is readable when keyed to the viewer's own session token; a product is readable when its parent show is publicly accessible. This matters more for Cartcast than for most products because the entire premise routes anonymous strangers on third-party sites into a multi-tenant database. On a surface with that threat model, the anonymous key failing open is the worst possible default. The anon key now fails closed. **The widget invisible to the main build.** The embed widget is a separate build artifact — an esbuild IIFE that produces a 3.4 KB self-contained JavaScript file with zero framework dependencies. The main build process does not build it, which means TypeScript and lint checks report green while the widget may be broken. The resolution was a dedicated widget build step that asserts zero framework imports in its output, run independently and committed as a static asset. **Features built and waiting for keys.** Live broadcast, VOD processing, AI show insights, instant merchant payouts, multi-host video rooms, and widget rate limiting are all built and gated. They become active when the operator provisions the respective external services — the streaming server, the AI provider, the queue service, Stripe Connect — through the admin integrations panel. All the application code is build-clean; the infrastructure is not pre-included in the purchase. ## What shipped Cartcast is a complete multi-tenant live-commerce platform: live broadcasts via RTMP and browser-native WebRTC, in-stream anonymous checkout with per-tenant Stripe Connect payouts, shoppable video replays keyed to database timestamps, and a full merchant product catalog, all delivered through a lightweight embed script. The platform is built for an operator who provides the service to merchants under a tiered subscription — the operator configures the plan tiers and sets the commission rate on live-attributed sales — with each merchant isolated as a tenant with separate payout accounts, embed-domain allowlists, and row-level security enforced throughout. The shape is the inverse of the marketplace: the audience stays on the merchant's own domain, where the merchant controls the brand experience and retains the customer relationship. The market evidence for this shape in the West is genuinely mixed. Cartcast is infrastructure for the operator who has already reached their own conclusion about the channel. ## See it [See Cartcast →](https://cartcast.saascode.ai) ## Related reading - [Cartcast vs Channelize.io vs Bambuser — Own the Platform or Subscribe to One](https://saascode.ai/inside/cartcast-vs-channelize-io-vs-bambuser-own-the-platform-or-subscribe-to-one.md) - [Live commerce software: a buyer's guide organised by who owns the audience](https://saascode.ai/inside/live-commerce-software-a-buyers-guide-organised-by-who-owns-the-audience.md)