A civic video platform for council meetings must encode, store, recommend, and serve recordings at scale. Which reference architecture lesson applies?
Select an answer to reveal the explanation.
Short Explanation
Council video is a media factory: encode it, park it, spice it with recommendations, then serve it cleanly. Email attachments and paper minutes are not that factory line.
Full Explanation
Streaming-media reference architectures separate encode, storage, enrichment (including recommenders), and large-scale serving. Civic meeting platforms inherit those stage boundaries so council recordings remain durable and discoverable for residents. Treating media as a staged pipeline is the architectural lesson, independent of consumer streaming brands.
Keeping meetings only as paper minutes and skipping digital media pipelines fails by concept: digital civic video needs the pipeline. Uploading raw camera feeds to email attachments as the serving tier fails by concept: email is not scalable serving. Disabling storage so recommendations run only on live unrecorded streams forever fails by concept: durable store is required for replay and enrichment.
Exam caveat: Follow encode → durable store → enrichment/recommend → scalable serve—not paper-only, email-attachment serving, or storage-less live-only designs.
Operational check: Implement encode and durable storage first, add enrichment/search, load-test serving for peak meeting views, and verify residents can find prior meetings. Document residual risk for civic operators and revisit after the next production change window. Confirm owners, SLAs, and rollback criteria in the runbook before go-live.