sync new docs mostly

docs/drafts/20100612_1_scaling.txt

@@ -1,3 +1,7 @@
+# Draft — source for SPEC/DR (rev. 2 — 2026-06-12)
+# SPEC: docs/specs/20100612_1_scaling.md
+# DR:  docs/DRs/20100612_1_scaling.md
+#
 The problem:
 Now we have a small VM instance which serves not so much of things. A short list of services include:
 - own web service (nginx+php) for UI/UX and some control panels, serving issues, tickets, graphs, build control (orchestration)
@@ -32,6 +36,17 @@ Ask AI to collect the information, make its decision based on all that we curren
 Also, the matter of seamless scaling is super important, better to have the load balancing ready to use just from cloud provider.
 Also, let AI think of how many simulatltaneous connections can we have per instance - the question is for RSSH implementation and future improvements
 
+Network bandwidth (missing in rev.1 — add to SPEC/DR):
+- we scale not only by CPU/RAM/connections but by **network throughput**: ingress/egress on FE WAN, FE→BE backhaul, per-VM NIC, CDN/object-store egress, SFU/ffmpeg media pipes, OTA/APK download storms, WireGuard UDP
+- need **budget metrics** per service (Mbps sustained, peak, GB/month egress) and alerts before link saturation
+- single FE uplink + single BE path is a hidden bottleneck today; cloud/hybrid phase must model **egress cost** (OTA, recordings, transcodes)
+
+Global availability and GEO (missing in rev.1 — add to SPEC/DR):
+- long-term: **the world can reach our services** (consoles, APIs, OTA, cast/signaling, short links, future commercial VPN) with acceptable latency — multi-region or CDN edge as we grow
+- simultaneously: **segment isolation by policy** — not all content or features in all countries; example: certain recordings, OTA builds, or published cast archives must **not** be offered in Zambia (ZM) or other denylisted regions unless PO overrides
+- enforcement should be layered: DNS/Geo routing, CDN/WAF geo rules, app/BE **geo_policy** on content objects, tenant RBAC — default allow globally, explicit **deny segments** per resource or catalog
+- dev/staging may stay single-region; prod gains GEO rules when F3 cast storage / F5 payments / F9 streaming go live
+
 The future key role requirements:
 - multipoint casting and routing outside the intra network, usage of 3rdparty or own multipoint solutions on the backends(MCU, SFU...)
 - new RBAC control, new roles - now we're thinking as developers and deliver the max of services to developers, but we will migrate to the other model sooner or later