Mengelola Pergeseran Program dalam Penjadwalan Drag-and-Drop

Ketika Anda bertanya kepada operator live-TV apa yang ingin mereka lihat dalam alat penjadwalan, mereka hampir selalu mengatakan, "Biarkan saya membangun saluran seperti cara saya mengatur file dalam folder. Seret program, jatuhkan di tempat yang saya inginkan, selesai.

Masalahnya adalah jadwal saluran bukanlah folder. Itu adalah dokumen hukum dengan batasan ketat. Dua program tidak dapat diputar pada saat yang bersamaan. Encoder tidak dapat mengganti input lebih cepat dari setiap lima detik. Program yang sudah dimulai tidak dapat diedit. Dan film yang diputar melewati tengah malam harus diperlakukan sebagai satu program, tidak dipotong pada batas hari.

Setiap tindakan drag-and-drop adalah potensi pelanggaran batasan yang menunggu untuk terjadi. Ini adalah cerita rekayasa tentang bagaimana penjadwal mStudio mengubah drag-and-drop yang ramah operator menjadi timeline saluran yang dijamin legal di AWS MediaLive — termasuk saat operator menjatuhkan program tepat di atas program lain — dan mengapa sistem menyelesaikan konflik tersebut secara otomatis alih-alih memberikan operator kesalahan dan teka-teki untuk dipecahkan.

Gambaran Cepat

Masalah Bisnis: Kalender yang Bukan Kalender

Penjadwalan saluran terlihat seperti perangkat lunak kalender. Operator berharap itu berperilaku seperti kalender — seret film ke slot pukul 9 malam, geser program di sepanjang timeline, tambahkan seri secara batch dan saksikan episode-episode tersebut tersusun berurutan. Tetapi jadwal saluran langsung memiliki batasan yang tidak dimiliki kalender:

• Program tidak boleh tumpang tindih. TV langsung memutar tepat satu hal pada satu waktu.
• Encoder memiliki jarak tindakan minimum. AWS MediaLive tidak akan mengganti input lebih cepat dari setiap 5 detik. Jadwalkan dua program dengan jarak 4 detik, dan deploy akan ditolak.
• Program yang sudah lewat tidak dapat diedit. Waktu tayang sudah berlalu; bit-bit sudah ada di layar pemirsa.
• Program lintas-tengah malam adalah satu unit. Film yang berjalan dari 23:30 hingga 01:15 harus ditangani sebagai satu program, bukan dua program setengah yang terpisah pada batas hari.

"Hampir tumpang tindih" dua detik bukanlah kesalahan operator — itu adalah hasil alami dari menyeret dua program yang hampir, tetapi tidak sepenuhnya, cocok. Tantangan rekayasa yang sebenarnya adalah menerjemahkan "seret film ke jam 9 malam" menjadi "jadwal saluran yang legal." Jika salah, operator akan menghadapi dinding kesalahan pada setiap penjatuhan, atau — lebih buruk lagi — mengetahui pada saat tayang bahwa encoder secara diam-diam menolak sebagian dari jadwal.

Apa Arti "Legal" di AWS MediaLive

Agar jadwal legal di MediaLive, program-program yang berdekatan haruslah:

1. Berurutan — tanpa jeda di antara keduanya, atau
2. Dipisahkan oleh setidaknya 5 detik — jarak tindakan minimum encoder.

Jebakannya adalah semua yang ada di antaranya. Jeda 1 detik, jeda 3 detik, jeda 4,9 detik — semuanya terlihat baik-baik saja di UI, dan semuanya ditolak saat deploy. Lebih buruk lagi, penolakan itu bukanlah kegagalan atomik yang bersih; itu dapat menghasilkan saluran yang sebagian ter-deploy, di mana beberapa tindakan jadwal berhasil di MediaLive dan yang lain tidak.

Tambahkan margin keamanan 1 detik untuk drift jam antara server aplikasi dan AWS, dan batas praktisnya menjadi 6 detik, bukan 5. Angka tunggal ini — MIN_NEIGHBOUR_GAP_MS = 6000 — adalah satu-satunya konstanta yang menjadi dasar seluruh sistem resolusi konflik.

Mengapa Pendekatan yang Jelas Gagal

Sebelum memutuskan resolusi otomatis, beberapa strategi yang lebih jelas dipertimbangkan dan ditolak:

"Tolak setiap ketidaksesuaian dan minta operator untuk menyelesaikannya." Karena itu, operator harus secara manual melakukan perhitungan snap pada setiap penjatuhan. Tarikan lima detik menjadi teka-teki lima menit, dan teka-teki menjadi lebih sulit seiring bertambahnya playlist. Dalam praktiknya, operator sepenuhnya meninggalkan drag-and-drop dan kembali ke spreadsheet.

"Jepit semuanya ke batas 5 menit agar tidak ada yang tumpang tindih." Ini menyelesaikan masalah teknis dengan menghancurkan niat operator. Program yang seharusnya dimulai pada 21:03:15 tidak boleh secara diam-diam melompat ke 21:05:00. Jadwal adalah milik operator, bukan fungsi pembulatan.

"Deteksi konflik pada waktu deploy alih-alih waktu drop." Ini terasa lebih cepat di UI, tetapi memindahkan kegagalan ke saat terburuk yang mungkin. Pada saat operator mengklik Deploy dan melihat "jadwal ditolak pada program 47," mereka secara mental sudah beralih dari pengeditan yang menyebabkannya.

"Izinkan celah mikro di UI dan biarkan MediaLive menolaknya." Ini mendorong kesalahan encoder yang tidak jelas langsung kembali ke operator, dan dapat meninggalkan saluran dalam keadaan setengah ter-deploy yang sangat sulit untuk dipulihkan.

Pengungkit yang benar-benar berhasil adalah menyelesaikan konflik secara otomatis, pada waktu drop, menggunakan aturan deterministik — dan segera merefleksikan timeline yang diperbaiki kembali kepada operator.

Solusi: Algoritma Snap Empat Aturan

Pada setiap drop, algoritma snap memeriksa setiap pasang program yang berdekatan di saluran yang terpengaruh — pasangan baru-ke-baru, baru-ke-yang sudah ada, atau yang sudah ada-ke-yang sudah ada yang jedanya berubah karena drop — dan menerapkan tepat satu dari empat aturan berdasarkan jeda di antara mereka:

• Jeda = 0 → tanpa tindakan. Berurutan adalah legal, dan hampir pasti itulah yang dimaksud operator.
• Jeda ≥ 6 detik → tanpa tindakan. Operator sengaja menyisakan ruang, kemungkinan untuk slate atau ad pod.
• 0 < jeda < 6 detik → geser program kedua ke belakang untuk menutup jeda menjadi nol.
• Jeda negatif (tumpang tindih) → geser program kedua ke depan sebesar jumlah tumpang tindih.

Yang krusial, algoritma memproses pasangan yang berdekatan dalam satu kali lintasan maju atas timeline yang sudah diurutkan. Setiap program yang digeser segera menjadi item "sebelumnya" untuk perbandingan berikutnya — sehingga drop yang memicu reaksi berantai pergeseran diselesaikan dalam satu lintasan linier, tanpa memerlukan rekursi.
Diagram 1 · Pohon Keputusan Snap

Arsitektur Sistem

Penjadwal dibangun di sekitar seperangkat komponen kecil dan terfokus:

• Backend NestJS (schedule.service.ts) memiliki snap walk, memoization cascade, dan kontrak tulis dengan MediaLive.
• Kueri tumpang tindih rentang waktu. Ketika drop tiba, backend menarik setiap program yang sudah ada yang jendela waktunya menyentuh rentang batch baru, ditambah buffer 6 detik di setiap sisi. Karena kueri ini beroperasi pada rentang waktu daripada tanggal kalender, program lintas-tengah malam ditangani secara identik dengan program lainnya — tidak ada logika batas tanggal khusus yang ada di mana pun dalam sistem.
• Timeline yang digabungkan. DTO program baru dan program yang sudah ada yang dikueri digabungkan menjadi satu daftar terurut. Snap walk berjalan terhadap timeline gabungan ini.
• Peta shiftedExistings. Untuk setiap program yang sudah ada yang disentuh oleh pergeseran, peta ini menangkap waktu mulai dan berakhir aslinya saat pertama kali disentuh — dan tidak pernah menimpanya pada sentuhan berikutnya. Struktur data tunggal inilah yang membuat cascade multi-langkah aman.
• Lambda DELETE_PROGRAM. Untuk setiap program yang digeser yang sudah di-deploy ke MediaLive, waktu aslinya dikirim ke fungsi Lambda untuk pembersihan sebelum MongoDB diperbarui.

• MIN_NEIGHBOUR_GAP_MS = 6000 — konstanta tunggal yang dirujuk oleh setiap aturan, setiap kueri tumpang tindih, dan setiap buffer keamanan.

   

Keputusan Rekayasa Kunci

1. Empat aturan, satu lintasan, tanpa kasus khusus. Empat aturan yang sama mencakup setiap skenario yang dapat dibuat operator: program baru yang dijatuhkan di antara dua program yang sudah ada, dua program baru yang berkonflik satu sama lain, atau program yang sudah ada yang terdorong ke dalam tumpang tindih oleh pergeseran sebelumnya dalam drop yang sama. Tidak ada jalur kode terpisah untuk semua ini — setiap kasus direduksi menjadi "memeriksa celah antara program yang berdekatan dan menerapkan aturan."

2. Enam detik, bukan lima. MediaLive memberlakukan jarak minimum 5 detik antara tindakan jadwal; menjadwalkan dua pergantian input dengan jarak 4,9 detik menyebabkan penolakan deploy. Sistem memberlakukan 6 detik — margin keamanan satu detik untuk clock drift antara jam backend dan AWS. Mengirimkan tindakan tepat pada 5.000 detik, ketika jam encoder membacanya sebagai 4.997 detik, menghasilkan penolakan intermiten yang terlihat seperti kegagalan jaringan dan terasa seperti bug yang tidak dapat direproduksi. Detik tambahan mengubah mode kegagalan intermiten menjadi mode yang tidak pernah terjadi.

Ini datang dengan tradeoff yang disengaja: batas bawah 6 detik berarti jeda kecil (3 atau 4 detik) yang berurutan akan tertutup rapat menjadi nol daripada dipertahankan. Tradeoff itu diterima dengan sengaja — transisi back-to-back bersih di MediaLive, dan jeda 3 detik yang terlihat cenderung tampak seperti gangguan bagi pemirsa terlepas dari itu.

3. Memoization waktu asli membuat cascade aman. Satu drop dapat memicu rantai pergeseran — program A menggeser B, B menggeser C, C menggeser D. Panggilan pembersihan ke MediaLive harus menargetkan waktu deploy asli setiap program, bukan waktu pergeseran cascade-nya; menggunakan waktu yang salah menyebabkan MediaLive merespons dengan "no action found," secara diam-diam menggagalkan pembersihan. Walk mempertahankan peta programId → {oldStartTime, oldEndTime}, yang diambil pertama kali setiap program disentuh. Pergeseran cascade selanjutnya hanya memperbarui timeline di memori; yang asli yang di-memoized tetap tidak tersentuh, dan pembersihan selalu menggunakan persis apa yang sebenarnya dicatat MediaLive.
Diagram 2 · Contoh Cascade
 

4. Penjagaan tanggal lampau, diberlakukan dalam dua fase terpisah. Edit tanggal lampau diblokir dua kali, secara sengaja:

• Fase 0, sebelum snap walk berjalan: setiap program baru dengan waktu mulai lebih awal dari "sekarang" menolak seluruh batch secara langsung, dengan kesalahan yang jelas. Snap walk bahkan tidak pernah berjalan terhadap input yang tidak mungkin.
• Fase 4, setelah snap walk: dua sub-kasus yang berbeda ditangani secara berbeda. Program baru yang secara tidak sengaja ditarik ke masa lalu oleh snap (jarang, tetapi mungkin pada batas waktu permintaan) secara diam-diam dikembalikan ke waktu aslinya, sebelum snap — niat operator dipertahankan, dan snap tidak diterapkan. Program yang sudah ada yang akan didorong ke masa lalu oleh pergeseran justru menolak seluruh batch — menyentuh program yang sudah mulai tayang tidak pernah menjadi sesuatu yang akan diserap secara diam-diam oleh sistem.

5. Kontrak penulisan Lambda-pertama, database-kedua. Ketika snap menggeser program yang sudah di-deploy ke MediaLive, MongoDB dan MediaLive sebentar tidak sinkron, dan urutan rekonsiliasi menjadi penting. Kontraknya: Lambda pertama, MongoDB kedua. Backend memanggil DELETE_PROGRAM di Lambda menggunakan waktu asli program; jika ada panggilan yang gagal, backend akan melempar error sebelum penulisan database apa pun terjadi. Hanya setelah setiap panggilan penghapusan berhasil, satu bulkWrite akan memperbarui MongoDB dengan waktu baru dan mengatur ulang isDeployed: false.

Ini menghasilkan satu invarian yang bersih: jika MongoDB menunjukkan program pada waktu baru, MediaLive telah menerima pergerakan itu. Jika operator melihat kesalahan, tidak ada sistem yang tersentuh. Tidak ada keadaan yang mungkin di mana MongoDB dan MediaLive secara diam-diam tidak setuju tentang waktu suatu program.

6. Hari reset memiliki jaring pengaman khusus. "Hari reset" menghapus setiap program di saluran untuk hari kalender tertentu — operasi paling destruktif dalam sistem — sehingga membawa dua perlindungan spesifik.

• Buffer 2 menit (SAFETY_BUFFER_MS = 120000) mengecualikan setiap program yang dimulai dalam dua menit berikutnya, memberikan jendela toleransi pemutaran langsung sehingga reset tidak pernah dapat bersaing dengan program yang akan tayang. 
• Preservasi carry-over mengecualikan program yang dimulai pada hari sebelumnya tetapi berlanjut ke hari ini — program-program tersebut termasuk jadwal kemarin, bukan hari ini. 

Tersedia juga fallback yang ramah: jika saluran belum pernah di-deploy ke MediaLive sama sekali, Lambda mengembalikan string kesalahan tertentu yang dipahami backend, mencatatnya sebagai no_infrastructure, dan kemudian melakukan penghapusan lunak hanya di MongoDB. Reset tetap berhasil; langkah AWS hanya menjadi no-op.

Mengapa Kombinasi Pilihan Desain Ini

Apa yang Masih Dipantau

Rekayasa yang jujur berarti menyebutkan celah yang masih terbuka, bukan hanya yang sudah teratasi.

• Edit bersamaan di saluran yang sama. Jika dua operator mengklik Deploy pada saluran yang sama dalam beberapa ratus milidetik satu sama lain, keduanya akan memuat snapshot yang sama, keduanya akan menjalankan snap walk secara independen, dan keduanya akan menulis ke MongoDB. Saat ini tidak ada kunci per saluran atau pemeriksaan versi optimis. Mitigasi saat ini bersifat operasional — satu operator memiliki satu saluran pada satu waktu — sementara perbaikan teknis, bidang versi pada dokumen saluran yang diperiksa pada waktu penulisan, ada dalam roadmap.
• Tidak ada umpan balik di UI untuk apa yang 'terjepit' (snapped). Ketika walk menggeser program sebanyak tiga detik, tampilan operator disegarkan ke keadaan yang diperbaiki, tetapi belum menunjukkan apa yang bergerak dan mengapa. Data sudah ada dalam payload respons; toast, sidebar, atau tampilan diff direncanakan untuk iterasi selanjutnya dari UI penjadwal.

Hasil

• Operator dapat menjatuhkan program di mana saja pada timeline, dan sistem membuat jadwal yang dihasilkan menjadi legal dalam satu lintasan deterministik — tanpa modal konflik, tanpa dinding kesalahan, tanpa perhitungan snap manual.
• Satu algoritma empat aturan mencakup setiap kasus — baru-vs-baru, baru-vs-yang sudah ada, dan pergeseran berantai melintasi batas hari — tanpa penanganan khusus untuk salah satunya.
• Program lintas-tengah malam dan transisi DST mengalir melalui kueri tumpang tindih rentang waktu yang sama dengan kasus lainnya; tidak ada "jalur kode tengah malam" terpisah untuk dipelihara.
• Hari reset tidak dapat secara tidak sengaja menghentikan program yang sedang tayang — buffer 2 menit dan preservasi carry-over berlaku untuk setiap saluran, setiap saat.
• Kontrak Lambda-pertama / database-kedua membuat drift jadwal secara diam-diam tidak mungkin terjadi: MongoDB dan MediaLive dijamin akan setuju, atau operator melihat kesalahan eksplisit.

• MIN_NEIGHBOUR_GAP_MS adalah satu-satunya kenop yang dapat disetel. Setiap margin keamanan, setiap aturan snap, dan setiap jendela tumpang tindih mereferensikannya, sehingga menyesuaikan definisi "legal" platform adalah perubahan satu baris.

   

Pemikiran Akhir

Hal paling menarik tentang sistem ini bukanlah aturan tunggal mana pun — melainkan seberapa sedikit aturan yang dibutuhkan. Empat kondisi pada nilai jeda, diterapkan dalam satu lintasan maju, mencakup setiap konflik yang dapat dibuat operator, termasuk cascade multi-langkah melintasi batas tengah malam. Itu adalah hasil desain yang disengaja: kompleksitas didorong ke dalam membuat aturan yang benar sekali, daripada menangani daftar kasus khusus yang terus bertambah.

Pelajaran yang lebih luas menggeneralisasi perangkat lunak penjadwalan masa lalu: ketika suatu sistem memiliki batasan eksternal yang ketat — jarak minimum encoder, jaminan konsistensi database, siaran langsung yang tidak dapat dibatalkan — tempat teraman untuk menegakkan batasan tersebut adalah dalam sejumlah kecil aturan deterministik yang diterapkan secara konsisten, bukan dalam penanganan ad hoc yang tersebar di seluruh codebase. Dan ketika dua sistem pencatatan (di sini, MongoDB dan MediaLive) harus tetap sinkron, mengurutkan penulisan sehingga kegagalan selalu meninggalkan mereka dalam keadaan yang diketahui dan disepakati layak dengan latensi tambahan yang dibutuhkan.
 

Tentang MicrocosmWorks

Di MicrocosmWorks, kami membangun perangkat lunak kelas produksi untuk organisasi yang memecahkan masalah rekayasa kompleks.

Keahlian kami meliputi aplikasi AI, platform SaaS, perangkat lunak enterprise, sistem cloud-native, teknologi media, dan arsitektur backend kustom.

Melalui blog rekayasa kami, kami berbagi pelajaran praktis yang dipelajari dari merancang dan mengoperasikan sistem produksi dunia nyata.

Lanjutkan Membaca

Jika Anda menikmati artikel ini, Anda mungkin juga menemukan topik-topik ini berguna:

• Membangun Arsitektur SaaS yang Skalabel
• Infrastruktur Cloud-Native
• Pemrosesan Video Enterprise dengan FFmpeg