A live-learning platform expects a synchronised audience for a single scheduled class. How should video delivery, interactive features, enrolment and notifications be architected differently from each other?

Four workloads with four different shapes

• Video delivery is enormous in bandwidth and trivially cacheable. It belongs entirely on a CDN with origin shielding, and it should never touch application infrastructure. A live stream is a small number of segments requested by everyone almost simultaneously, which is the best possible cache profile — provided requests are collapsed so a segment's first request is the only one that reaches origin.
• Interactive features (chat, polls, questions) are the hard part: many small messages, fan-out to a large audience, low latency, and no caching. This needs a purpose-built path — persistent connections, per-room partitioning, and aggressive aggregation. A chat message fanned out individually to a very large audience is a write-amplification problem, and the answer is batching and rate limiting rather than more capacity.
• Enrolment and access checks are a burst of writes in the minutes before start. Pre-compute entitlement, cache it, and make the check a local token validation rather than a database query.
• Notifications are a large fan-out with a soft deadline. Queue them, spread them over minutes, and respect the downstream provider's quotas.

The most common mistake

Treating all four as one system and scaling it uniformly. The bandwidth-heavy workload needs a CDN, the latency-heavy one needs connection management, the write-burst one needs pre-computation, and the fan-out one needs a queue. Uniform scaling gives all four the wrong shape and costs several times what the correct decomposition costs.

Degradation, in order

Chat becomes read-only or sampled before video quality drops. Poll results update less frequently. Notifications are delayed. Video playback is the last thing to degrade, and even then it degrades by lowering bitrate rather than by failing — because the product is the class, and everything else is an enhancement.

The cost dimension

For an education platform with price-sensitive customers, bandwidth is usually the dominant cost, which makes encoding ladder choices, segment length and cache hit ratio architectural decisions with direct margin consequences. A five-percentage-point improvement in cache hit rate is worth more than most application optimisations, and it is achieved by request collapsing, longer segment TTLs and consistent URL construction — not by adding capacity.