მონაცემთა ნაკადები კვანძებს შორის

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

1) მიზანი და მიზანი

• პროგნოზირება: სტაბილური SLO შეფერხების/წარმატების/სიახლის თვალსაზრისით.
• საიმედოობა: დანაკარგების წინააღმდეგობა, დუბლიკატები, რეგორგები.
• უსაფრთხოება და შესაბამისობა: დაშიფვრა, ხელმოწერები, რეზიდენტობა.
• მასშტაბურობა: გეო განაწილება, განაწილება, QoS.

2) ნაკადების ტაქსონომია

1. Control Plane: კონფიგურაცია, ძაფები, მარშრუტიზაციის/ლიმიტის პოლიტიკა.
2. Data Plane - ღონისძიება: აფეთქების ღუმელის მოვლენები ('deposit.', 'payout.', 'bridge.').
3. Data Plane - ნაკადი: გრძელი ნაკადები (GRPC/WebSocket) სიგნალებისა და ცოცხალი მეტრიკისთვის.
4. Batch/Backfill: გადმოტვირთვის ისტორიული ნაჭრები, რაფები, snaphots.
5. რეპლიკაცია/ანტი-ენტროპია: სახელმწიფო სინსი, მერკლიზაცია, CRDT ნაკადები.
6. Telemetria/დაკვირვება: logs/metrics/trais side-band, არ ერევა მთავარ UX.

თითოეული ტიპი შეესაბამება QoS კლასებს და საკუთარი რეაგირების/წესრიგის წესებს.

3) ტოპოლოგია და მარშრუტიზაცია

Hub and Spoke: რეგიონალური კერა საბურავები; სპოკები - როლების კვანძები.
Mesh/P2P: ნაწილობრივი ქსელის სიმძიმე რეპლიკაციისთვის/გოსიპისთვის.
Edge-Tiered: თხელი edge-limit/ქეში - სქელი რეგიონალური მტევანი.
Geo-Routing: Anycast/Latency-Aware LB + რეზიდენციის წესები.

საკვანძო - ნაწილობრივი განლაგება: 'partition _ key = chainId' tenant 'topic' entityID 'იძლევა პროგნოზირებად წესრიგს და მასშტაბს.

4) ტრანსპორტი და ფორმატები

HTTP/2/3, gRPC/QUIC - დაბალი ლატენტობა, მულტიპლექსაცია, კეპალივი.
Kafka/Pulsar/NATS - ხაზები კონფიდენციალურობით/პარტიებით/საკონსულტაციო ჯგუფებით.
WebSocket არის push მოვლენები და ცოცხალი არხები.
ფორმატები: Protobuf/Avro (ევოლუციის სქემები), JSON გარე API- სთვის.
Hash მისამართები და Merkle ქვითრები მთლიანობის გადამოწმებისთვის.

5) შეკვეთა, მიწოდება და დასრულება

• At-least-once (ნაგულისხმევი; საჭიროა idempotence/dedup).
• Exactly-once ეფექტი Outbox/Inbox + Idempotent კონსიუმერის საშუალებით.
• ბრძანება: გარანტირებულია პარტიაში; ინტერპარტიული პროცედურა გარანტირებული არ არის.
• ფინალიზაცია: 'observed' confirmed (K) სტატუსები და finalized invalidated (reorg) '; optimistic- ისთვის - დავის ფანჯარა.

6) იდემპოტენტობა და დედობა

• `idempotency_key = ${chainId}|${block}|${tx}|${logIndex}|${type}`

• კონფლიქტზე payload არის „ჭეშმარიტების წყარო“ პოლიტიკა (პრიორიტეტი, ვერსია, ხელმოწერა).
• HTTP მოთხოვნებისთვის - სათაური 'Idempotency-Key' + პასუხის ჟურნალი.

7) რიგები, backpressure და კვოტები

რიგები: მხარეები გასაღებით; DLQ „შხამიანი“ შეტყობინებებისთვის.
Backpressure: სესხები/ნიშნები, შეზღუდვა max-inflight, circuit-breaker.
კვოტები/QoS: P0 (კრიტიკული), P1 (პროდუქტი), P2 (bulk). ცალკეული აუზები/limites RPS/bytes/s/ხელმოწერები.
Admission Control: „ძვირადღირებული“ მოთხოვნების ადრეული უარყოფა, დიაპაზონი/ზომა.

8) მონაცემთა კოორდინაცია და მოდელები

Read-you-write ნაწილში/კვანძში.
საღამოს კონსულტაცია რეგიონებს/პარტიებს შორის.
CRDT ზოგიერთი კომპლექტის რეპლიკაციისთვის (მრიცხველები, ნაკრები).
Snaphots + ჟურნალები სწრაფი bootstrap და დეტერმინისტული რეპლეი.

9) უსაფრთხოება და ნდობა

mTLS კვანძებს შორის, გასაღების დაფა, როტაცია.
შეტყობინებების/ვებჰუკების ხელმოწერები, დროის ნიშანი და ანტი-replay ფანჯარა.
გზის დაშიფვრა/მარტო; რეგიონალური გასაღებების სეგრეგაცია.
PII მინიმიზაცია: ტოკენიზაცია, პერსონალური მონაცემების აკრძალვა ეტიკეტებში/მეტრიკებში.

10) ეფექტურობა: შეფუთვა, კომპრესია, ქეში

Batching: მცირე შეტყობინებების ჯგუფი overhead- ის შესამცირებლად.
Compression: zstd/gzip უსაფრთხო ლექსიკონებით.
ქეში: უარყოფითი პასუხები და „ცხელი“ ცნობარები; TTL და ღონისძიების ინვალიდობა.

11) მონაცემთა სქემები (რეფერენდუმი)

ნაკადის/წვეულებების რეესტრი

sql
CREATE TABLE streams (
name TEXT PRIMARY KEY,
partitions INT,
qos TEXT,        -- P0    P1    P2 retention_days INT,
schema_version TEXT
);

CREATE TABLE offsets (
stream TEXT, partition INT, consumer_group TEXT,
offset BIGINT, updated_at TIMESTAMPTZ,
PRIMARY KEY (stream, partition, consumer_group)
);

ღონისძიების ჟურნალი (idempotent upsert)

sql
CREATE TABLE events_core (
id UUID PRIMARY KEY,
idempotency_key TEXT UNIQUE,
ts TIMESTAMPTZ,
partition_key TEXT,
type TEXT,
payload JSONB,
status TEXT,      -- observed    confirmed    finalized    invalidated signature TEXT
);

DLQ/კარანტინი

sql
CREATE TABLE dlq (
id UUID PRIMARY KEY,
stream TEXT, partition INT, offset BIGINT,
reason TEXT, payload JSONB, ts TIMESTAMPTZ
);

12) პოლიტიკა (YAML)

QoS და ლიმიტები

yaml qos:
P0: { ack_timeout_ms: 2000, retries: 3, backoff_ms: [100,400,800], rps_per_org: 1500 }
P1: { ack_timeout_ms: 5000, retries: 2, rps_per_org: 800 }
P2: { best_effort: true, rps_per_org: 200 }
limits:
max_message_bytes: 1048576 max_stream_subscriptions_per_client: 20

ფინალიზაცია და ფანჯრები

yaml finality:
eth-mainnet: { k: 12 }
polygon:   { k: 256 }
optimistic: { k: 0, challenge_minutes: 20 }

Routing/რეზიდენცია

yaml routing:
prefer_local_region: true fallback: [nearest_healthy, master_hub]
residency:
eu: ["eu"]
uk: ["uk"]

13) დაკვირვება: SLI/SLO

• Latency p95/p99 (ingress→egress, per-stream/QoS).
• Success Rate / Drop Rate.
• Queue Lag p95 და consumer lag წვეულებებზე.
• Freshness p95 (ingest→consume).
• Reorg/Invalidated Rate (თუ ონჩეინი).
• Dedup Efficiency (% დუბლი შეიწოვება იდემპოტენტურად).
• Geo-Hit Ratio (ადგილობრივად ემსახურება).

• P0 latency p95-400 ms; Success ≥ 99. 95%; Queue-lag p95 ≤ 2 с; Freshness p95 ≤ 60 с.
• Dedup efficiency ≥ 99%; DLQ ≤ 0. ტრეფიკის 1%.

დაშბორდები: Streams Core/Lag & Freshness/QoS & Errors/Geo/Security (mTLS/ხელმოწერები).

14) მომხმარებელთა ნიმუშები

Outbox/Inbox: ატომური პუბლიკაცია და იდემპოტენტური გამოყენება.
Exactly-once ეფექტი: შეინახეთ ბოლო გამოყენებული გასაღები და ვერსია.
Watermarks: დაგვიანებული მოვლენების დამუშავება.
Idempotent Side-Effects: გარე მოთხოვნები მხოლოდ გასაღებით და პასუხის ჟურნალით.

15) დეგრადაციის რეჟიმები

Finalized-only mode: ჩვენ ვაძლევთ მხოლოდ საბოლოო მოვლენებს.
Cache-only საცნობარო წიგნებისთვის, მძიმე მეთოდების გაყინვა.
Throttle P2 და „დიეტის რეჟიმი“ ნაკადებისთვის (შემცირებული განახლების სიხშირე).
Read-only მცირე API- სთვის.

16) გამოშვებები და მიგრაცია დასრულების გარეშე

Blue-Green/Canary ნაკადები და კონსიუმერები.
Schema-first: მხოლოდ ველების დამატება; MAJOR არის ტოპიკის პარალელური ვერსიები.
Offset's მიგრაცია: shadow კონსუტერები, lag/წარმატების შედარება, გადართვა.

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

ყოველდღიურად: SLO ანგარიში (latency/success/lag/freshness), ხელმოწერის აუდიტი, DLQ შემოწმება.
ყოველკვირეულად: წვეულებების/კვოტების გადასინჯვა, DR ტესტი (snapshot bootstrap), Dedup Efficiency- ის ანალიზი.
ყოველთვიურად: chaos ტესტები (loss/jitter, ბროკერის უარი, reorg-burst), ფინანსური ფანჯრების გადასინჯვა.
გამოშვებამდე: კანარი - 120 წუთი, SLO კარიბჭე, დაბრუნების გეგმა.

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

A. Queue-Lag/Consumer-Lag აფეთქება

1. კონსიუმერების გაზრდა/KEDA; 2) პარტიების გადანაწილება; 3) გაყინვა P2 და ბულკის ჯობი; 4) ცხელი გასაღებების ანალიზი.

B. Rost p95 Latency P0

1. P2 throttle, პრიორიტეტული P0; 2) განაწილება საკეტები/ბროკერები; 3) ქეში მხოლოდ საცნობარო წიგნებისთვის; 4) outlier-ejection.

C. მაღალი DLQ/დუბლირება

1. იდემპოტენტურობის გასაღები/TTL; 2) ბაბუის გაძლიერება; 3) შეზღუდოს ხმაურიანი პროდიუსერი; 4) ფრჩხილის შემდეგ.

D. Drift სქემები/კონტრაქტები

1. ჩართეთ strict-mode (შეწყვიტეთ არასასურველი); 2) აცნობეთ პროდიუსერს; 3) ადაპტერის გამოშვება; 4) განაახლეთ ლინტერი.

E. რეზიდენციის/ხელმოწერების დარღვევა

1. ექსპორტის/არხის ბლოკი; 2) გასაღების/სერიის როტაცია; 3) აუდიტი და პოსტ-mortem; 4) პოლიტიკოსის განახლება.

19) განხორციელების სია

1. განსაზღვრეთ ნაკადის ტიპები და გარიგების გასაღები.
2. ჩართეთ idempotence/dedup და ფინალიზაცია K/დავის ფანჯრებთან.
3. შემდეგი რიგები, QoS, კვოტები და დაბომბვა.
4. MTLS/ხელმოწერები და რეზიდენციის პოლიტიკა.
5. შეიყვანეთ სქემები/რეესტრები (streams, offsets, dlq) და SLI/SLO ტელემეტრია.
6. მოაწყეთ canary/blue-green და სქემების მიგრაცია დასრულების გარეშე.
7. შეიმუშავეთ დეგრადაციის რეჟიმები და ინციდენტების ფლეიბუკები.

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

Backpressure - შეყვანის დატვირთვის კონტროლი (სესხები/ნიშნები/ლიმიტები).
DLQ არის „მკვდარი ხაზი“ პრობლემური შეტყობინებებისთვის.
CRDT არის მონაცემთა სტრუქტურა კონფლიქტის მოგვარების გარეშე კოორდინაციის გარეშე.
Finality არის მოვლენის/მდგომარეობის შეუქცევადობა.
Exactly-once ეფექტი არის უსაფრთხო შედეგი at-least-once მიწოდების თავზე.
Watermark არის შემდგომი მოვლენების დამუშავების პროგრესის ნიშანი.
Outlier-ejection არის აუზიდან დეგრადირებული ინსტანციების გამორიცხვა.

შედეგი: კვანძებს შორის მონაცემთა ნაკადები არ არის მხოლოდ „ხაზი და მსმენელი“, არამედ წესრიგის, ფინალიზაციის, იდემპოტენტურობის, უსაფრთხოებისა და დაკვირვებების სისტემური დისციპლინა. სტანდარტული კონვერტაციის გასაღებები, QoS/კვოტები, მკაცრი სქემები და SLO, დეგრადაციის რეჟიმებთან და პლეიბუკებთან ერთად, ეკოსისტემას აძლევს სტაბილურ მონაცემთა გადაცემის არხებს მასშტაბით და აუდიტის ქვეშ.