Managing Program Shift in Drag-and-Drop Scheduling

When you ask any live-TV operator what they would want to see in a scheduling tool, they nearly invariably say, "Let me build a channel the way I organize files in a folder. Drag a program in, drop it where I want it, done.

The problem is that a channel schedule isn't a folder. It's a legal document with hard constraints. Two programs can't play at the same moment. The encoder can't switch inputs faster than every five seconds. A program that already started can't be edited. And a movie that runs past midnight has to be treated as one program, not sliced at the day boundary.

Every drag-and-drop action is a potential constraint violation waiting to happen. This is the engineering story of how mStudio's scheduler turns operator-friendly drag-and-drop into a guaranteed-legal channel timeline on AWS MediaLive — including the moment an operator drops a program directly on top of another one — and why the system resolves those conflicts automatically instead of handing the operator an error and a puzzle to solve.

Quick Overview

The Business Problem: A Calendar That Isn't a Calendar

Channel scheduling looks like calendar software. Operators expect it to behave like one — drag a movie into a 9 PM slot, slide programs up the timeline, batch-add a series and watch the episodes lay themselves out back-to-back. But a live channel schedule carries constraints a calendar simply doesn't have:

• Programs are not allowed to overlap. Live TV plays exactly one thing at a time.
• The encoder has a minimum action spacing. AWS MediaLive won't switch inputs faster than every 5 seconds. Schedule two programs 4 seconds apart, and the deploy is rejected.
• Past programs can't be edited. Air time has already passed; the bits are already on viewers' screens.
• Cross-midnight programs are one unit. A movie running from 23:30 to 01:15 has to be handled as a single program, not two half-programs split at the day boundary.

An "almost overlap" of two seconds isn't operator error — it's the natural result of dragging two programs that almost, but not quite, fit together. The real engineering challenge is translating "drag a movie to 9 PM" into "a legal channel schedule." Get it wrong, and the operator either hits an error wall on every drop, or — worse — discovers at air time that the encoder silently rejected part of the schedule.

What "Legal" Means on AWS MediaLive

For a schedule to be legal on MediaLive, adjacent programs must be either:

1. Back-to-back — zero gap between them, or
2. Separated by at least 5 seconds — the encoder's minimum action spacing.

The trap is everything in between. A 1-second gap, a 3-second gap, a 4.9-second gap — all of them look perfectly fine in a UI, and all of them get rejected at deploy time. Worse, the rejection isn't a clean, atomic failure; it can result in a partially-deployed channel, where some schedule actions landed on MediaLive and others didn't.

Add a 1-second safety margin for clock drift between application servers and AWS, and the practical floor becomes 6 seconds, not 5. This single number — MIN_NEIGHBOUR_GAP_MS = 6000 — is the one constant the entire conflict-resolution system is built around.

Why the Obvious Approaches Fail

Before settling on automatic resolution, several more obvious strategies were considered and rejected:

"Reject any disagreement and request that the operator resolve it." Because of this, operators must manually perform snap math on each drop. A five-second drag becomes a five-minute puzzle, and the puzzle gets harder as the playlist grows. In practice, operators abandon drag-and-drop entirely and fall back to spreadsheets.

"Snap everything to 5-minute boundaries so nothing ever overlaps." This solves the technical problem by destroying the operator's intent. A program meant to start at 21:03:15 should not silently jump to 21:05:00. The schedule belongs to the operator, not to a rounding function.

"Detect conflicts at deploy time instead of drop time." This feels faster in the UI, but it moves the failure to the worst possible moment. By the time the operator clicks Deploy and sees "schedule rejected at program 47," they've mentally moved on from the edit that caused it.

"Allow micro-gaps in the UI and let MediaLive reject them." This pushes opaque encoder errors straight back to the operator, and can leave the channel in a half-deployed state that's genuinely hard to recover from.

The lever that actually worked was resolving conflicts automatically, at drop time, using deterministic rules — and reflecting the corrected timeline back to the operator immediately.

The Solution: A Four-Rule Snap Algorithm

On every drop, a snap algorithm examines each pair of adjacent programs on the affected channel — new-to-new, new-to-existing, or existing-to-existing pairs whose gap changed because of the drop — and applies exactly one of four rules based on the gap between them:

• Gap = 0 → no action. Back-to-back is legal, and is almost certainly what the operator intended.
• Gap ≥ 6 seconds → no action. The operator deliberately left room, likely for a slate or an ad pod.
• 0 < gap < 6 seconds → shift the second program backward to close the gap to zero.
• Negative gap (overlap) → shift the second program forward by the overlap amount.

Crucially, the algorithm processes adjacent pairs in a single forward pass over the sorted timeline. Each shifted program immediately becomes the "previous" item for the next comparison — so a drop that triggers a chain reaction of shifts resolves in one linear walk, with no recursion required.
Diagram 1 · The Snap Decision Tree

System Architecture

The scheduler is built around a small, focused set of components:

• NestJS backend (schedule.service.ts) owns the snap walk, the cascade memoization, and the write contract with MediaLive.
• Time-range overlap query. When a drop arrives, the backend pulls every existing program whose time window touches the new batch's range, plus a 6-second buffer on each side. Because this query operates on time ranges rather than calendar dates, cross-midnight programs are handled identically to any other program — no special date-boundary logic exists anywhere in the system.
• Merged timeline. The new program DTOs and the queried existing programs are merged into a single sorted list. The snap walk runs against this combined timeline.
• shiftedExistings map. For any existing program touched by a shift, this map captures its original start and end times the first time it's touched — and never overwrites them on subsequent touches. This one data structure is what makes multi-step cascades safe.
• Lambda DELETE_PROGRAM. For any shifted program that was already deployed to MediaLive, its original times are sent to a Lambda function for cleanup before MongoDB is updated.

• MIN_NEIGHBOUR_GAP_MS = 6000 — the single constant every rule, every overlap query, and every safety buffer references.

   

Key Engineering Decisions

1. Four rules, one walk, no special cases. The same four rules cover every scenario an operator can create: a new program dropped between two existing ones, two new programs that conflict with each other, or an existing program that's pushed into overlap by an earlier shift in the same drop. There is no separate code path for any of these — every case reduces to "examine the gap between adjacent programs and apply the rule."

2. Six seconds, not five. MediaLive enforces a 5-second minimum spacing between schedule actions; scheduling two input switches 4.9 seconds apart causes a deploy rejection. The system enforces 6 seconds — a one-second safety margin for clock drift between the backend's clock and AWS's. Submitting an action at exactly 5.000 seconds, when the encoder's clock reads it as 4.997 seconds, produces intermittent rejections that look like network failures and feel like unreproducible bugs. The extra second converts an intermittent failure mode into one that simply never fires.

This comes with a deliberate tradeoff: a 6-second floor means small back-to-back gaps of 3 or 4 seconds get snapped closed to zero rather than preserved. That tradeoff was accepted intentionally — back-to-back transitions are clean on MediaLive, and a visible 3-second gap tends to look like a glitch to viewers regardless.

3. Original-time memoization makes cascades safe. A single drop can trigger a chain of shifts — program A shifts B, B shifts C, C shifts D. The cleanup call to MediaLive must target each program's original deployed time, not its cascade-shifted time; using the wrong time causes MediaLive to respond with "no action found," silently failing the cleanup. The walk maintains a map of programId → {oldStartTime, oldEndTime}, captured the first time each program is touched. Later cascade shifts update only the in-memory timeline; the memoized originals stay untouched, and cleanup always uses exactly what MediaLive actually has on record.
Diagram 2 · A Cascade Example
 

4. Past-date guards, enforced in two separate phases. Past-dated edits are blocked twice, deliberately:

• Phase 0, before the snap walk runs: any new program with a start time earlier than "now" rejects the entire batch outright, with a clear error. The snap walk never even runs against an impossible input.
• Phase 4, after the snap walk: two distinct sub-cases are handled differently. A new program that the snap accidentally pulled into the past (rare, but possible at request-time clock boundaries) is silently reverted to its original, pre-snap time — the operator's intent is preserved, and the snap is simply not applied. An existing program that a shift would push into the past instead rejects the entire batch — touching a program that has already started airing is never something the system will silently absorb.

5. A Lambda-first, database-second write contract. When a snap shifts a program that's already been deployed to MediaLive, MongoDB and MediaLive are briefly out of sync, and the order of reconciliation matters. The contract: Lambda first, MongoDB second. The backend calls DELETE_PROGRAM on Lambda using the program's original times; if any call fails, the backend throws before any database write happens. Only once every delete call succeeds does a single bulkWrite update MongoDB with the new times and reset isDeployed: false.

This produces one clean invariant: if MongoDB shows a program at a new time, MediaLive has already accepted that move. If the operator sees an error instead, neither system was touched. There is no possible state where MongoDB and MediaLive silently disagree about a program's time.

6. Reset day has its own dedicated safety net. "Reset day" deletes every program on a channel for a given calendar day — the single most destructive operation in the system — so it carries two specific protections.

• A 2-minute buffer (SAFETY_BUFFER_MS = 120000) exempts any program starting within the next two minutes, giving live playback a grace window so a reset can never race with a program about to go to air. 
• Carry-over preservation excludes programs that started the previous day but spill into today — those belong to yesterday's schedule, not today's. 

A gracious fallback is also available: if a channel has never been deployed to MediaLive at all, Lambda returns a certain error string that the backend understands, logs as no_infrastructure, and then performs a MongoDB-only soft deletion. The reset still succeeds; the AWS step simply becomes a no-op.

Why This Combination of Design Choices

What's Still Being Watched

Honest engineering means naming the gaps that remain open, not just the ones that are solved.

• Concurrent edits on the same channel. If two operators click Deploy on the same channel within a few hundred milliseconds of each other, both will load the same snapshot, both will run the snap walk independently, and both will write to MongoDB. There's no per-channel lock or optimistic version check today. The current mitigation is operational — one operator owns one channel at a time — while the technical fix, a version field on the channel document checked at write time, is on the roadmap.
• No in-UI feedback for what snapped. When the walk shifts a program by three seconds, the operator's view refreshes to the corrected state, but doesn't yet surface what moved and why. The data already exists in the response payload; a toast, sidebar, or diff view is planned for the next iteration of the scheduler UI.

Results

• Operators can drop a program anywhere on the timeline, and the system makes the resulting schedule legal in one deterministic pass — no conflict modals, no error walls, no manual snap math.
• A single four-rule algorithm covers every case — new-vs-new, new-vs-existing, and cascading shifts across day boundaries — without special-casing any of them.
• Cross-midnight programs and DST transitions flow through the same time-range overlap query as any other case; there is no separate "midnight code path" to maintain.
• Reset day cannot accidentally take a live program off air — the 2-minute buffer and carry-over preservation apply to every channel, every time.
• The Lambda-first / database-second contract makes silent schedule drift impossible: MongoDB and MediaLive are guaranteed to agree, or the operator sees an explicit error.

• MIN_NEIGHBOUR_GAP_MS is the single tunable knob. Every safety margin, every snap rule, and every overlap window references it, so adjusting the platform's definition of "legal" is a one-line change.

   

Final Thoughts

The most interesting thing about this system isn't any single rule — it's how few rules were needed. Four conditions on a gap value, applied in one forward pass, cover every conflict an operator can create, including multi-step cascades across midnight boundaries. That's a deliberate design outcome: complexity was pushed into getting the rules right once, rather than into handling an ever-growing list of special cases.

The broader lesson generalizes past scheduling software: when a system has hard external constraints — an encoder's minimum spacing, a database's consistency guarantees, a live broadcast that can't be un-aired — the safest place to enforce those constraints is in a small number of deterministic rules applied consistently, not in ad hoc handling scattered across the codebase. And when two systems of record (here, MongoDB and MediaLive) must stay in sync, ordering the writes so that failure always leaves them in a known, agreeing state is worth the extra latency it costs.
 

About MicrocosmWorks

At MicrocosmWorks, we build production-grade software for organizations solving complex engineering problems.

Our expertise includes AI applications, SaaS platforms, enterprise software, cloud-native systems, media technology, and custom backend architecture.

Through our engineering blog, we share practical lessons learned from designing and operating real-world production systems.

Continue Reading

If you enjoyed this article, you may also find these topics useful:

• Building Scalable SaaS Architectures
• Cloud-Native Infrastructure
• Enterprise Video Processing with FFmpeg