MicrocosmWorksNag-iinobasyon at Nagdidisenyo ng Digital Cosmos
Tungkol Sa AminMakipag-ugnayan
MicrocosmWorksNagpapabago at Nagdidisenyo ng Digital Cosmos

Nagbibigay ng mga solusyong IT na mahalaga. Kami ay masigasig sa teknolohiya, seguridad, at pagtulong sa mga negosyo na lumago sa pamamagitan ng maaasahan, makabagong IT infrastructure.

[email protected]
+91 7011868196
New Delhi, India

Sentro ng Paglago ng AI

AI HubInobasyon ng StartupPampabilis ng Negosyo

Mga Solusyon

Lahat ng SolusyonMga Wellness at Fitness AppsAI Video PlatformPag-unlad ng AI Agent

Mga Mapagkukunan

Mga PananawMga Gabay sa IndustriyaMga Plano ng PaggamitMga Pattern ng ArkitekturaMga Pag-aaral ng Kaso

Kumpanya

Tungkol sa AminMakipag-ugnayanAng Aming Gawain

Mga Serbisyo

Digital na PagkonsultaImprastraktura ng CloudPag-unlad ng SaaSPag-unlad ng AITeknolohiya ng Video
Pag-unlad ng ERPPagpapasadya ng ZohoPag-unlad ng OdooPagsasama ng SalesforcePag-unlad ng Custom na CRM
Pagsasama ng QuickBooksMga Solusyon sa IoTPag-unlad ng Blockchain
Pagkonsulta sa CybersecuritySuporta sa IT - L3

© 2026 MicrocosmWorks. Lahat ng karapatan ay nakalaan.

Patakaran sa PagkapribadoMga Tuntunin ng Serbisyo
Bumalik sa mga Case Study
AI SurveillanceNa-publish June 22, 2026 · Na-update June 22, 2026

Auto-Scaling RTSP Streaming Architecture na may Dual Orchestrators at Zero Packet Drop

Kailangan ng isang surveillance platform na i-scale ang video streaming infrastructure nito nang dynamic — mula sa paghawak ng 10 hanggang 200+ IP cameras na may daan-daang sabay-sabay na manonood at AI processing workers — habang tinitiyak ang zero packet loss sa panahon ng scaling operations at pagpapanatili ng stable stream URLs na hindi nagbabago.

Pag-usapan ang Iyong Proyekto
rtsp-streaming-autoscale-mediamtx.webp
AI Surveillance
Domain
11
Technologies
6
Key Results
Delivered
Status

Ang Hamon

Hindi kayang hawakan ng fixed streaming infrastructure ang variable demands ng lumalaking surveillance platform:

  • Pagkakaiba-iba ng Scale — Ang bilang ng camera at demand ng manonood ay nagbabago nang malaki sa buong araw (10x peak-to-trough ratio)
  • Gastos ng Over-Provisioning — Ang paglalaan para sa peak load ay nangangahulugang 70%+ idle resources sa mga oras na hindi peak
  • Packet Loss sa Panahon ng Scaling — Ang pagdaragdag o pag-aalis ng streaming servers ay nagdulot ng pagkaantala sa stream, bumabagsak ang mga frame para sa AI processing workers
  • Instabilidad ng URL — Ang mga camera at manonood na naka-configure sa mga partikular na server IPs ay nangangailangan ng reconfiguration kapag nagbago ang infrastructure
  • Magkaibang Pangangailangan sa Scaling — Ang camera ingestion at viewer distribution ay may fundamentally different load patterns na nangangailangan ng independent scaling
  • Pagkagambala ng AI Worker — Ang mga AI processing pipelines ay nagka-crash kapag ang kanilang source stream server ay na-scale down

Ang Aming Solusyon

Dinisenyo namin ang isang dual-orchestrator auto-scaling streaming architecture na may hiwalay na ingestion at distribution clusters, isang 5-phase graceful shutdown para sa zero packet drop, stable DNS-based URLs, at automated AI worker reconnection.

Arkitektura

  • Streaming Server: MediaMTX para sa RTSP/WebRTC/HLS protocol support
  • Ingestion Cluster: 1-10 servers na tumatanggap ng camera RTSP streams
  • Distribution Cluster: 2-20 servers na nagsisilbi sa mga manonood (WebRTC/HLS) at AI workers (RTSP)
  • Dual Orchestrators: Independent scaling controllers para sa ingestion at distribution
  • Load Balancers: Hiwalay na load balancers bawat cluster na may protocol-appropriate algorithms
  • Service Registry: Redis para sa server status, stream mappings, at coordination
  • Health Monitoring: Aktibong health checks na may automated recovery
  • DNS Layer: Stable domain names na tumuturo sa load balancers (hindi nagbabago ang URLs)

Disenyo ng Dual Orchestrator

Bakit Dalawang Orchestrators

Ang ingestion at distribution ay may fundamentally different scaling characteristics:

  • Ingestion ay nag-scale sa bilang ng camera at inbound bandwidth (predictable, lumalaki nang tuloy-tuloy)
  • Distribution ay nag-scale sa bilang ng manonood at demand ng AI worker (bursty, unpredictable)

Ang magkahiwalay na orchestrators ay nagpapahintulot sa bawat isa na mag-scale nang independent sa pamamagitan ng specialized policies, metrics, at thresholds — nang hindi naaapektuhan ng scaling decisions ng isang cluster ang isa pa.

Ingestion Orchestrator

  • Primary Metric: Camera connections per server
  • Secondary Metric: Inbound bandwidth utilization
  • Scale Up: Kapag ang CPU ay lumampas sa threshold o ang cameras per server ay lumampas sa kapasidad
  • Scale Down: Kapag ang utilization ay bumaba sa threshold para sa isang sustained stabilization period
  • Server Range: 1 hanggang 10 servers

Distribution Orchestrator

  • Primary Metric: Viewer + AI worker connections per server
  • Secondary Metric: Outbound bandwidth utilization
  • Scale Up: Kapag ang CPU ay lumampas sa threshold o ang connections per server ay lumampas sa kapasidad
  • Scale Down: Kapag ang utilization ay bumaba sa threshold para sa isang sustained period (mas mahabang stabilization kaysa sa ingestion)
  • Server Range: 2 hanggang 20 servers (minimum 2 para sa high availability)

Zero Packet Drop: 5-Phase Graceful Shutdown

Kapag ang isang distribution server ay nakatakdang alisin, isang 5-phase na proseso ang tinitiyak na walang frames ang mawawala:

Phase 1: Pre-Notification

Ang server ay minarkahan bilang "DRAINING" sa service registry. Ang timbang ng load balancer ay binawasan upang ang mga bagong koneksyon ay mag-route sa ibang lugar. Ang Redis pub/sub notifications at webhooks ay nag-aalerto sa AI workers upang maghanda para sa migration.

Phase 2: Load Balancer Update

Ang server ay inalis mula sa load balancer backend pool. Walang bagong koneksyon ang makakarating sa draining server. Ang mga umiiral na koneksyon ay nagpapatuloy nang walang pagkaantala.

Phase 3: AI Worker Migration

Ang AI workers ay nagdi-disconnect mula sa draining server at nagre-reconnect sa healthy distribution servers. Ang checkpoint-based state preservation ay tinitiyak na ang processing ay nagre-resume mula sa eksaktong frame kung saan ito huminto. Kabuuang gap: humigit-kumulang 3 segundo na walang frames na nawala.

Phase 4: Viewer Draining

Ang natitirang viewer connections ay natural na nag-drain sa isang configurable window. Ang modernong video players ay awtomatikong nagre-reconnect sa parehong stable URL, na nagre-route sa healthy servers. Karamihan sa mga manonood ay hindi nakakaranas ng pagkaantala.

Phase 5: Cleanup

Siguraduhin na ang lahat ng koneksyon ay sarado na. Alisin ang server mula sa service registry. Sirain ang cloud instance. I-record ang scaling metrics.

Stable URLs

Ang URL architecture ay tinitiyak na ang mga camera at kliyente ay hindi kailanman nangangailangan ng reconfiguration:

  • Camera publish target: Isang stable ingestion domain name
  • Viewer/AI access target: Isang stable distribution domain name
  • Ang DNS records ay tumuturo sa load balancer IPs (na permanente)
  • Ang load balancers ay humahawak sa routing sa backend servers nang transparent
  • Ang backend servers ay maaaring idagdag, alisin, o palitan nang walang pagbabago sa URL

Service Registry (Redis)

Isang centralized Redis instance ang nagko-coordinate sa buong sistema:

  • Pagsubaybay sa server status (active, draining, offline)
  • Stream-to-server mapping (kung aling camera ang nasa aling ingestion server)
  • AI worker state at checkpoint data
  • Load metrics per server para sa scaling decisions
  • Pub/sub channels para sa real-time coordination events

AI Client Reconnection

Isang AI client library ang nagbibigay ng seamless reconnection:

  • Nakikinig para sa server removal notifications sa pamamagitan ng Redis pub/sub
  • Awtomatikong frame checkpointing sa regular na mga interval
  • Reconnection sa isang healthy distribution server sa notification
  • Mag-resume ng processing mula sa checkpoint na may minimal gap
  • Metrics reporting para sa reconnection events

Health Monitoring

  • Aktibong health checks sa bawat server sa regular na mga interval
  • Awtomatikong pag-update ng load balancer sa mga server failures
  • Auto-recovery triggers para sa unresponsive servers
  • Pagsubaybay sa uptime at availability reporting

Mga Pangunahing Tampok

  1. Dual Orchestrators — Independent scaling para sa ingestion at distribution clusters
  2. Zero Packet Drop — 5-phase graceful shutdown na may AI worker migration
  3. Stable URLs — DNS-based routing na tinitiyak na hindi nagbabago ang URLs sa panahon ng scaling
  4. AI Worker Reconnection — Checkpoint-based migration na may ~3 second gap at zero frame loss
  5. Independent Scaling — Ang ingestion at distribution ay nag-scale batay sa kanilang sariling metrics
  6. Service Registry — Redis-based coordination para sa server status at stream mappings
  7. Health Monitoring — Aktibong checks na may awtomatikong recovery
  8. Cost Optimization — Awtomatikong scale-down sa panahon ng mababang demand

Mga Resulta

Packet Loss: 0.00% para sa AI workers sa panahon ng scaling operations
AI Reconnection: ~3 segundo na may checkpoint-based resume
Scale Up Time: ~60 segundo mula sa trigger hanggang sa serving

Technology Stack

MediaMTXPythonFastAPIRedisDockerCloud VM APIsLoad BalancersDNSPrometheusGrafanaWebSocket

caseStudyDetail.more Mga Case Study

Tuklasin ang higit pa sa aming mga teknikal na implementasyon

AI Accounting

Pagpoproseso ng Invoice na Pinapagana ng AI gamit ang OCR at Integrasyon ng QuickBooks

Isang katamtamang laking negosyo na nagpoproseso ng daan-daang invoice ng vendor buwan-buwan ang kinailangan alisin ang manu-manong pagpasok ng data sa pamamagitan ng awtomatikong pagkuha ng data ng invoice gamit ang AI/OCR at direktang i-sync ito sa QuickBooks para sa bookkeeping at pagsubaybay sa pagbabayad.

Basahin ang Case Study
Video Encoding

Client-Side Ad Insertion (CSAI) na may pag-parse ng SCTE-35 Marker at Integrasyon ng Multi-Platform Player

Isang platform para sa video streaming ay nangangailangan na magpatupad ng Client-Side Ad Insertion (CSAI) sa mga web, mobile, at connected TV apps — na nagbibigay-daan sa mga personalized, device-level na karanasan sa ad na may buong suporta sa interaksyon ng ad (mga clickable overlay, companion banner, skip button) na hindi kayang ibigay ng server-side insertion.

Handa nang Baguhin ang Iyong Negosyo?

Pag-usapan natin kung paano namin mailalapat ang katulad na mga solusyon sa iyong mga hamon.

Makipag-ugnayancaseStudyDetail.viewAllCaseStudies
Scale Down Time: ~220 segundo na may full graceful shutdown
URL Stability: 100% — walang pagbabago sa URL sa anumang scaling events
Uptime: 99.95% system availability
Basahin ang Case Study
Web Scraping

Platform sa Pag-scrape at Pagbuo ng Nilalaman ng Blog na Pinapagana ng AI

Isang kumpanya ng media ang nangailangan ng matalinong platform ng nilalaman na kayang i-automate ang paggawa ng nilalaman ng blog sa pamamagitan ng pag-scrape ng kasalukuyang nilalaman ng web, pagsusuri nito gamit ang AI, at pagbuo ng orihinal, naka-optimize para sa SEO na mga post sa blog mula sa nakuha na datos.

Basahin ang Case Study

Mga Madalas Itanong

Nagpatupad ang MicrocosmWorks ng isang active-active dual orchestrator design kung saan ang parehong orchestrator ay nagpapanatili ng synchronized state tungkol sa mga stream assignment at worker health, na may automatic failover na naglilipat ng stream management sa nakaligtas na orchestrator sa loob ng ilang segundo kung isa ang mag-fail. Inaalis nito ang single point of failure na dinaranas ng tradisyonal na single-orchestrator design, tinitiyak ang zero packet drop sa panahon ng orchestrator maintenance o hindi inaasahang pag-crash.

Ang MicrocosmWorks ay nagdisenyo ng isang graceful drain mechanism kung saan ang mga retiring workers ay patuloy na nagseserbisyo ng kanilang nakatalagang stream hanggang ang lahat ng koneksyon ay malinis na mailipat sa mga bagong workers sa pamamagitan ng RTSP TEARDOWN at re-SETUP na mga sequence. Ang mga bagong workers ay ganap na na-initialize at na-health-check bago makatanggap ng mga stream assignment, at ang transisyon ay gumagamit ng mga overlapping window kung saan ang luma at bagong workers ay sabay na nagseserbisyo ng iisang stream sa maikling panahon upang maiwasan ang anumang pagkaantala.

Pinili ng MicrocosmWorks ang MediaMTX para sa proyektong ito dahil ito ay magaan, open-source, at partikular na idinisenyo para sa RTSP re-streaming na may minimal na overhead ng resource bawat stream kumpara sa mga full-featured media server. Sinusuportahan nito ang dynamic na paggawa ng stream sa pamamagitan ng API, tumatakbo nang mahusay sa mga container para sa auto-scaling na batay sa Kubernetes, at iniiwasan ang mga gastos sa paglilisensya bawat stream ng mga komersyal na alternatibo tulad ng Wowza na maaaring maging labis na mahal sa malaking sukat.

Ang MicrocosmWorks ay nag-deploy ng isang komprehensibong observability stack na sumusubaybay sa mga per-stream metric kabilang ang packet loss rate, jitter, reconnection count, at end-to-end latency, na may mga alert na nagpa-fire bago pa maging kapansin-pansin ang degradation sa mga end user. Sinusubaybayan din ng monitoring system ang mga orchestrator decision-making metric tulad ng scaling events, stream migration durations, at worker utilization trends upang makatulong sa proactive capacity planning.

Oo, dinisenyo ng MicrocosmWorks ang mga worker node upang suportahan ang sabay-sabay na RTSP output para sa mga live viewer at segmented recording sa object storage, na may independiyenteng resource allocation para sa bawat workload. Gumagamit ang recording ng hiwalay na write path na nagba-buffer ng mga segment nang lokal bago i-upload, kaya ang mga storage I/O spike ay hindi kailanman nakakaapekto sa live stream delivery, at isinasaalang-alang ng auto-scaler ang pinagsamang resource demand ng parehong workload kapag gumagawa ng mga desisyon sa pag-scale.