რეგიონალური ჰაბები

(განყოფილება: ეკოსისტემა და ქსელი)

1) რატომ გვჭირდება რეგიონალური ჰაბები

• ლატენტობა და UX: მომხმარებელთან სიახლოვე (RTT, TTI/TTF).
• შესაბამისობა და რეზიდენცია: მონაცემთა შენახვა/დამუშავება იურისდიქციის შიგნით.
• სტაბილურობა და შესაძლებლობები: გლობალური ბირთვის გადმოტვირთვა, მუშაობა რეგიონის ნაწილობრივი იზოლაციით.
• ეკონომიკა: ინტერრეგიონალური ტრაფიკის შემცირება, ადგილობრივი CDN/ქეში, მომგებიანი ტარიფები IX/peering.

2) რეგიონალური კერა

1. Edge/Gateway - შეყვანის ფენა (HTTP/2/3, GRPC, WebSocket, QUIC), rate-limit, QoS, WAF.
2. Reader/API - RPC, ინდექსები, საძიებო მომსახურება, ადგილობრივი materialized views.
3. Compute/Stream - მოვლენების დამუშავება, შეკუმშვა, ანტი-ფროიდის ფილტრები.
4. Data Plane - TSDB/სვეტების ფანჯრები, ობიექტის საცავი „თბილი“ მონაცემებისთვის.
5. Compliance/KYC/KYB არის ადგილობრივი ინტეგრაცია პროვაიდერებთან და სანქციების კატალოგებთან.
6. Payments/PSP - ადგილობრივი გადახდის მეთოდები და on/of-ramp.
7. Bridge/Relay არის ინტერჯგუფური შეტყობინებების ტერმინალი ადგილობრივი ფინალიზაციის ბუფერით.
8. Observability - მეტრიკა/ლოგები/ტრეისი, სინთეზური ნიმუშები.
9. მთავრობის/წვდომის - როლების, გასაღებების და შეზღუდვების კატალოგები რეგიონალური მონაწილეებისთვის.

3) განლაგების ტოპოლოგია

Hub and Spoke: ცენტრალური „სამაგისტრო კერა“ + რეგიონალური სპოკები ნაწილობრივი ავტონომიით.
Active-Active (Multi-Primary): რამდენიმე კერა სიმეტრიული მუშაობა კონფლიქტის რეპლიკაციით (CRDT/მოწინავე ჟურნალები).
Active-Passive: ცხელი რეზერვი პერიოდული რეპლიკაციით და DR როლიკებით.
Edge-Tiered: „თხელი“ edge კვანძები (CDN, WebSocket-fan-out) - „სქელი“ რეგიონალური კერა.

არჩევანი დამოკიდებულია საბოლოო/თანმიმდევრულობის, არხების ღირებულებისა და მარეგულირებელი შეზღუდვების მოთხოვნებზე.

4) რეზიდენციის გეომარსტრუტიზაცია და პოლიტიკა

GeoDNS/Anycast + Latency-Aware LB: ჩვენ ვაგზავნით თხოვნებს უახლოეს ჯანმრთელ კერაში.
Jurisdiction Routing: სუბიექტების მონაცემები (EU/UK/TR და ა.შ.) რჩება შესაბამის კერაში; რეგიონალური გადაზიდვები - მხოლოდ თეთრი სიების მიხედვით.
რეგიონებისთვის Traffic SOR (Smart Order Routing): ითვალისწინებს RTT- ს, არხის ღირებულებას, შესაბამისობის დროშებს, კვოტების დატვირთვას და SLO- ს.
Fail-in-Place: საგარეო ურთიერთობათა დეგრადაციის დროს, კერა აგრძელებს „ფინანსური-მხოლოდ“ მოთხოვნების მომსახურებას და ადგილობრივ ოპერაციებს.

5) მონაცემები: კატალოგები, რეპლიკაცია, შენახვის კლასები

• P0 - გადახდა/ხიდი/იდენტიფიკაცია (მკაცრი რეზიდენცია, „სიგნალების“ სინქრონიზაცია მხოლოდ ერთეულებში/უხეში).
• P1 - სასურსათო მოვლენები და აგრეგატები (ადგილობრივი vye + პერიოდული ექსპორტი).
• P2 - გამართვა/ლოგები (აგრესიული შეკუმშვა, რეგიონში გრძელი გადაკეთება).

• მოვლენები - ლოგიკური შიპინგი, რომელშიც შეკვეთილია წვეულება.
• საცავი - ასინქრონული MMR/CRDT ან snapshot-bacaps.
• რეზიდენცია: DLP/PII პოლიტიკოსები, ტოკენიზაცია, per-region- ის დაშიფვრის ცალკეული გასაღებები.

6) პროდუქტიულობა და ქეშირება

ქეში: edge-cash (მოკლე TTL), read-through on API, negative cache.
Warm Data: ბოლო N ბლოკი/ბრძოლა, ცხელი ინდექსები პოპულარული მეთოდების მიხედვით.
DA/Batch ბუფერები L2/ხიდებისთვის: მტკიცებულებების მქონე პუბლიკაციების ადგილობრივი რიგი.
Hardware-Adjusted TPS: ტევადობის დაგეგმვა/TPS და/RPS, რეგიონალური ფასების გათვალისწინებით.

7) QoS, რიგები და დაბომბვა

კლასები P0/P1/P2 საბურავების და კარიბჭეების დონეზე; ცალკეული ხაზები და კვოტები.
Partitioning: გასაღები 'region' tenant 'topic' პროგნოზირებადი throughput- ისთვის.
DLQ: „შხამიანი“ შეტყობინებების კარანტინი, ჯიტერი.
Admission Control: „ძვირადღირებული“ RPC- ის შეზღუდვა (დიაპაზონის, ფილტრების, ლიმიტების მიხედვით).

8) SLI/SLO რეგიონალური კერა

• P95 Latency (Edge/API), Success Rate, Queue-Lag p95, Finality p95 (ხიდი/რელე), Geo-Hit Ratio (რეგიონში მომსახურებული მოთხოვნების წილი), კომპლექსის Pass%.

• Edge/API p95 ≤ 350–450 мс, Availability ≥ 99. 95%.
• Freshness (P1) p95-3 წუთი; Queue-Lag P0 p95 ≤ 2 с.
• Geo-Hit Ratio - 85% (რეგიონთაშორისი ჰოპის გარეშე).
• DR RTO - 15 წუთი, RPO - 5 წთ P0.

9) დაკვირვება და დაშბორდები

Ops Core: latency/error/queue-lag/throughput QoS კლასებში.
Geo View: RTT თერმული რუკა, Geo-Hit Ratio, რეგიონთაშორისი ტრაფიკი.
კომპლექსი: რეზიდენცია, სანქციების ჰიტები, ექსპორტი-ლოგები.
Bridge/DA: p95, challenge/reorg ფინალიზაცია, პუბლიკაციების უარყოფა.
Capacity & Cost: TPS _ per _ $, CTS/1k მოთხოვნა, Utilization%.

10) DR და სტაბილურობა

სარეზერვო არხები: დამოუკიდებელი IX/პროვაიდერები, დაშიფრული ინტერკაბიური კავშირების გვირაბები.
იზოლირებული რეჟიმი: „finalized-only“, დეგრადაციური API, ადგილობრივი ქვითრები, რასაც მოჰყვა reconcile.
რეგულარული წვრთნები: ტრანსატლანტიკური გათიშვა, DA/provers- ის დაკარგვა, საზღვრებში „ჯიტერი/ზარალი“.

11) ეკონომიკა და დაგეგმვა

CTS (Cost-to-Serve) per 1k ops: არხები + გაანგარიშება + შენახვა + ლიცენზია.
TPS _ per _ $: სტაბილური გამტარუნარიანობა 1 დოლარის ინფრასტრუქტურისთვის.
Peering/IX ოპტიმიზაცია: ადგილობრივი peer წერტილები, პრეფიქსი ანონსი, შეკუმშვა და ტრამპლინი.
Tier მოდელი: T1 (სერვისების მაღარო), T2 (სრულმასშტაბიანი ანალიტიკა), T3 (სრული დასტის + DA/ხიდი).

12) კონფიგურაციის რეფერენდუმი

12. 1 მარშრუტიზაციის პოლიტიკა (YAML)

yaml routing:
geodns:
regions: [eu, uk, tr, la, apac, na]
policies:
prefer_local: true fallback_chain: [nearest_healthy, master_hub]
compliance:
residency:
eu: ["eu"]
uk: ["uk"]
tr: ["tr"]
export_whitelist:
eu: ["anonymized_metrics","hash_anchors"]
slo_gates:
p0_latency_p95_ms: 400 queue_lag_p95_ms: 2000

12. 2 K8s: Edge კარიბჭე + HPA

yaml apiVersion: apps/v1 kind: Deployment metadata: { name: edge-gw, labels: { region: eu } }
spec:
replicas: 4 template:
spec:
containers:
- name: gw image: org/edge-gw:2. 7. 0 ports: [{ containerPort: 443 }]
env:
- { name: QOS_CLASSES, value: "P0,P1,P2" }
- { name: DENY_HEAVY_RANGE, value: "eth_getLogs>5000" }
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: edge-gw-hpa }
spec:
minReplicas: 4 maxReplicas: 24 metrics:
- type: Pods pods:
metric: { name: request_latency_p95_ms }
target: { type: AverageValue, averageValue: 350m }

12. 3 კაფკა: რეგიონისთვის/ტენტანტისთვის განლაგება

yaml topic: "events. p0"
partitions: 96 config:
min. insync. replicas: 2 cleanup. policy: delete compression. type: zstd message. timestamp. type: CreateTime

12. 4 რეზიდენტობისა და ექსპორტის პოლიტიკა

yaml data_policy:
pii: { tokenized: true, cross_region_export: "deny" }
exports:
anonymized_metrics: { allowed: ["eu","uk","na"], schedule: "5m" }
hash_anchors: { allowed: ["eu","uk","na","apac"], cadence: "15m" }

13) მონაცემთა სქემები და მოთხოვნები

ჰაბებისა და კავშირების კატალოგი

sql
CREATE TABLE hubs (
hub_id TEXT PRIMARY KEY,
region TEXT, tier SMALLINT, status TEXT,
rtt_ms INT, cost_per_1k_ops NUMERIC,
created_at TIMESTAMPTZ
);

CREATE TABLE interlinks (
src_hub TEXT, dst_hub TEXT,
capacity_mbps INT, cost_per_gb NUMERIC,
encrypted BOOLEAN, health TEXT,
PRIMARY KEY (src_hub, dst_hub)
);

Geo-Hit Ratio и Freshness

sql
SELECT region,
100. 0 SUM(CASE WHEN served_in_region THEN 1 ELSE 0 END)/COUNT() AS geo_hit_pct,
PERCENTILE_CONT(0. 95) WITHIN GROUP (ORDER BY freshness_s) AS freshness_p95
FROM req_stats
WHERE ts >= now() - INTERVAL '24 hours'
GROUP BY region;

TPS_per_$

sql
SELECT hub_id,
AVG(tps_sustained) / NULLIF(AVG(cost_usd_hour),0) AS tps_per_usd
FROM hub_perf
WHERE ts >= now() - INTERVAL '7 days'
GROUP BY hub_id;

14) ოპერაციული რეგულაციები

ყოველდღიურად: SLO ანგარიში (latence/queue-lag/freshness), ექსპორტის/რეზიდენციის აუდიტი, ინტერკაბიური სახეების მდგომარეობა.
ყოველკვირეულად: კვოტების/QoS და GeoDNS კალიბრაცია, CTS/TPS _ per _ $ დათვლა, ქეშის გადასინჯვა და „ცხელი“ ინდექსები.
ყოველთვიურად: DR სავარჯიშოები (იზოლირებული რეჟიმი, არხების გადართვა), DA/ხიდების შემოწმება.
გამოშვებამდე: კანარის rollout თითო კერა/რეგიონი, SLO კარიბჭე და დაბრუნების გეგმა.

15) Playbook ინციდენტები

A. ინტერრეგიონალური არხის დაცემა

1. გადართეთ სარეზერვო IX- ზე, ჩართეთ შეკუმშვა/ბატჩი;

2. ჰერა „ფინალიზებულ-მხოლოდ“ რეჟიმში;

3. ექსპორტის ხაზი - ბუფერში, ლიმიტით;

4. კომუნიკაცია მონაწილეებთან, პოსტ-შურისმაძიებელი.

B. ადგილობრივი API p95 დეგრადაცია

1. პრიორიტეტული P0, ჩართეთ P2-throttle;

2. გაზარდეთ შენიშვნები edge/API;

3. ჩართეთ ქეში მხოლოდ ცხელი მეთოდებისთვის;

4. მძიმე მოთხოვნის დიაგნოზი, საჭიროების შემთხვევაში, დენის რულეტები.

C. რეზიდენციის დარღვევა

1. ჯვარედინი რეგიონალური ექსპორტის დაუყოვნებელი ბლოკი;

2. Redaction/ექსპორტის საპირისპირო;

3. შეტყობინება DPO/Compliance;

4. პოლიტიკოსისა და ტესტების განახლება.

. Piki reorg/DA უარყოფა

1. დავის ფანჯრის გაზრდა;

2. ჩართეთ „delayed finalization“;

3. აცნობეთ მომხმარებლებს;

4. შეავსეთ მოხსენებები.

E. ჰაბების არათანაბარი დატვირთვა

1. GeoDNS/Latency-LB გადაკეთება;

2. კვოტების/ფასების ბალანსი;

3. Affiliats/წყაროებისთვის ტრაფიკი.

16) განხორციელების შემოწმების სია

1. შეარჩიეთ რეგიონები/იურისდიქციები და მიზნობრივი SLO.
2. დააპროექტეთ ტოპოლოგია (Hub-Spoke ან Active-Active), არხები/IX.
3. როლების გაყოფა: Edge/API/Compute/Data/Bridge/Compliance.
4. ჩამოაყალიბეთ რეზიდენცია, კატალოგები და ექსპორტის პოლიტიკოსები.
5. ჩართეთ QoS, რიგები, ქეში და backpressure.
6. გაზარდეთ დაკვირვება და დაშბორდები Geo/Compliance/Perf/Cost.
7. კონფიგურაცია DR (RTO/RPO), წვრთნები და იზოლირებული რეჟიმი.
8. დაიწყეთ ეკონომიკური მეტრიკა (CTS, TPS _ per _ $) და ბიუჯეტი.

17) გლოსარიუმი

Geo-Hit Ratio არის მოთხოვნების წილი, რომელსაც ემსახურება „მათი“ კერა.
RPO/RTO - მონაცემთა დაკარგვის/აღდგენის დროის მიზნები.
Hub and Spoke არის ცენტრალური კვანძი პერიფერიული მტევნებით.
CRDT არის free კონფლიქტის სტრუქტურა.
CTS per 1k ops - მომსახურების ღირებულება 1000 ოპერაციისთვის.
TPS _ per _ $ - დოლარის ინფრასტრუქტურის გამტარუნარიანობა.

შედეგი: რეგიონალური ჰაბები გლობალურ ქსელს ადგილობრივად ოპტიმიზირებულ, კომპოზიციურ და სტაბილურ დომენებად აქცევს. მკაფიო SLO, რეზიდენტობა, QoS და DR პროცედურები, ისინი ამცირებენ ლატენტურობას და ღირებულებას, ზრდის საიმედოობას და უზრუნველყოფენ ეკოსისტემის მასშტაბს კონტროლის დაკარგვის გარეშე.