ურთიერთქმედების ზოგადი ოქმები

1) რატომ არის ეკოსისტემა ერთიანი ოქმები

ეკოსისტემის შემადგენლობაში შედიან ოპერატორები, სტუდიები/RGS, აგრეგატორები, PSP/APM, KYC/AML პროვაიდერები, აფილიატები და ანალიტიკური სერვისები. ურთიერთქმედების ზოგადი ოქმები გამორიცხავს ინტეგრაციის „ზოოპარკს“, აჩქარებს ონბორდინგს, ამცირებს მხარდაჭერის ღირებულებას და ინციდენტების რისკებს და ასევე უზრუნველყოფს თავსებადობას მასშტაბის დროს (ჰორიზონტალური, ვერტიკალური და დიაგონალური).

მიზნები: „ყუთიდან“ თავსებადობა, პროგნოზირებადი SLO, მონაცემთა უსაფრთხოება, მიგრაციის რეპროდუქცია.

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

HTTP/2/3, gRPC - სინქრონული API- სთვის დაბალი ლატენტობით; WebSocket - ნაკადის მოვლენებისთვის/ლიდერებისთვის; WebRTC (SRTP/QUIC) - აუდიო/ვიდეო ლაივ შინაარსისთვის.

• JSON - გარე B2B API და ვებჰუკი (კითხვა).
• Protobuf/Avro - შიდა საბურავი/ღრმა ინტეგრაცია (სქემის შეკუმშვა/ევოლუცია).
• შეკუმშვა/binding: gzip/br JSON- ისთვის; zstd Protobuf/Avro- სთვის.
• ლოკალი/დრო: ISO-8601 UTC- ში, თანხები - მინიმალური ფულადი ერთეულებში (integer).

3) ავთენტიფიკაცია, ავტორიზაცია, ნდობა

OAuth2/OIDC კლიენტებისთვის/პარტნიორობისთვის (მოკლე გზა ნიშნები, PKCE, სკოპები).
mTLS S2S- ისთვის სანდო ზონებს შორის; JWS/HMAC - მოთხოვნისა და ვებჰუკების ხელმოწერა.
RBAC/ABAC: როლები და ატრიბუტები (იურისდიქცია, ტენანტი, რისკის დონე).
გასაღებები და როტაცია: KMS/Vault, მოკლე სიცოცხლის ხანგრძლივობა, ავტომატური როტაცია (JWKS ჩათვლით).
Egress კონტროლი, დომენების ალოუ სია და ASN, DNSSEC/DoT/DoH მგრძნობიარე ზონებში.
Tenant isolation: per-tenant გასაღებები, კვოტები, ლიმიტები, namespace-s საბურავებში.

4) API კონტრაქტები (REST/gRPC) - კანონი

ვერსია: '/v {n '' URI- ში REST; 'package. vN 'for grRPC. Minor ევოლუცია უიღბლო; გადახედვის ცვლილებები - ახალი მაიორით. პოლიტიკური დეპრესია (იხ. § 12).
Idempotence: 'Idempotence-Key' POST/PUT/PATCH ფულადი/კრიტიკული ოპერაციების შესახებ; შენახვა N საათზე.
პაგინაცია: კურსორები ('nextPageToken'), არა 'offset/limit'; თანმიმდევრული დახარისხება.
ლიმიტები: '429 Too Many Requests' + კვოტების სათაურები ('X-RateLimit-'), რეაგირების ჯიტერი.
შეცდომები: მანქანების წაკითხული კოდები/ქვეკოდები, 'correlationId', ველების რუკა.
Taimauts and retrai: ექსპონენციალური შეფერხება + jitter; ნუ დახარჯავთ სახიფათო შეცდომებს.
თავსებადობის პოლიტიკა: ველების მნიშვნელობის უცვლელი; ახალი ველები არჩევითია.

5) მოვლენის მოდელი და საბურავი (EDA)

სქემების რეგისტრატორი: კონტრაქტი თითოეული ღონისძიებისთვის, ევოლუცია ბუკვარდის თავსებადობით.

• `click`, `session`, `bet`/`spin`, `round_start`/`round_result`,
• `deposit`/`withdrawal`, `psp_auth`, `kyc_status`, `fraud_signal`,
• `reward_granted`, `leaderboard_update`, `feature_toggle`.
• წვეულებების გასაღებები: 'playerId', 'campailId', 'tableId', 'operate Id' (დომენის არჩევანი).
• ადგილზე მიტანა: at-last-once ბიზნეს idempotence; ფულადი შედეგისთვის - საგა/txn-outbox.
• ბრძანება: „გარანტირებული ბრძანება გასაღების შიგნით“, ჯვარედინი გასაღებები - ორკესტრის საშუალებით.
• დროის სემანტიკა: 'eventTime' + 'ingestTime'; დედოპი '(eventId' idempotencyKey) ".

6) ვებჰუკი და მიწოდების გარანტიები

ხელმოწერა: JWS/HMAC 't' (timestamp) და 'kid', ფანჯრის შემოწმება ± 5 წუთი, აკრძალულია კონკურენცია.
Retrai: backoff ერთად ჯიტერი T წუთამდე, მცდელობების დაფიქსირება, გადინება მხოლოდ 5xx/timeout- ზე.
Idempotence: 'eventId' + სხეულის ხელმოწერა; დამუშავება „ერთხელ მაინც“.
ვებჰუკების მოვლენების რეესტრი: ისტორიის ხელახალი ნიმუში რასინქრონიზაციის დროს.
უსაფრთხოება: mTLS, როგორც ეს შესაძლებელია, allow-list IP/ASN, CSRF არ გამოიყენება სერვერის კოლბეკებზე.

7) მონაცემები და კონფიდენციალურობა (Privacy-by-Design)

PII მინიმალიზაცია: იდენტიფიკატორების ტოქსიკაცია ('playerId' ფსევდონიმი), მონაცემთა დომენების გამიჯვნა.
მონაცემთა კონტრაქტები: DPA/DPIA, მიზნები, შენახვის დრო, ტრანსსასაზღვრო ნაკადები (Whitelist ქვეყნები).
აუდიტის პოლიტიკა/ხაზი: ვინ/როდის/რატომ; უცვლელი ლოგოები (WORM).
RG/ეთიკის წესები: აგრესიული ოფისის აკრძალვა დაუცველი სეგმენტებისთვის; მკაფიო იურიდიული ბაზა.

8) კოორდინაცია და გარიგებები

ძლიერი თანმიმდევრულობა - საფულე/ბალანსი/გადახდა.
ღონისძიება - ფანჯრები, ლიდერები, ტელემეტრია.
განაწილებული ბიზნეს გარიგების საგები; გაუქმების ანაზღაურება.
Exactly-once ბიზნეს მნიშვნელობის თვალსაზრისით: idempotent გასაღებები და დეტერმინისტული დამტენი.

9) დაკვირვება და SLO

ტრეისი: 'TraceId- ის გავლა კლიკიდან/webhuk- დან გადახდამდე/ჯილდოზე; propagation (`W3C traceparent`).
მეტრიკი: p50/p95/p99 API, ბროკერის ლაგი, CR გადახდები/KUS, ლიდერები E2E.
ლოგოები: სტრუქტურირებული, PDN- ის გარეშე; ტოკენის/გასაღებების შენიღბვა.
SLO ფურცლები: ლოგინი p95-300-500 ms; ანაბარი p95-1. 5–2. 0 გვ; ფსონი/spin p95-150-250 ms; ღონისძიების მიტანა 99. 9%.

10) პროდუქტიულობა, კვოტები, ქარიშხლისგან დაცვა

Rate limiting (token/leaky bucket) L7- ზე და Mesh-პოლიტიკოსების მიერ.
Backpressure: ხაზები მყიფე აფსიდის წინ (PSP/KYC).
Outlier-ejection: არასტაბილური ზურგჩანთების ავტომატური „გაცივება“.
Circuit-breaker: ნაკადის დახურვა შეცდომების/ლატენტობის ბარიერების გადაჭარბებისას.
სამართლიანი წრე: კვოტები ტენანტის/არხის/რეგიონის მიხედვით; კრიტიკული დომენების პრიორიტეტი.

11) SDK თავსებადობა და ტესტის კრიტერიუმები

SDK ნაკრები: HTTP/gRPC მომხმარებლები, მოთხოვნის ხელმოწერა, ჯიტერის რეაგირება, იდემპოტენტობა, კურსორები.
საკონტრაქტო ტესტები: Postman/Newman/gRPC-conformance, PSP/KYC/სტუდიების სიმულატორები.
თავსებადობის მატრიცა: API/SDK ვერსიები, მხარდაჭერილი სქემები, დეპრესიის პოლიტიკა.
სინთეზური: მოვლენებისა და გარიგების გენერატორები, „შავი ყუთები“ 24/7 მონიტორინგისთვის.

12) ვერსიები და დეპრესიები (Change Management)

მთავარი გამოშვებები N- თვეში ერთხელ, პარალელური ფანჯრით 6-12 თვის განმავლობაში.
Minor ცვლილებები - სურვილისამებრ ველების/მეთოდების დამატება.
დეპრესია: გაფრთხილების გამოცხადება სათაურებში/პასუხებში, დროშა მეტრიკებში, გამორთვა გეგმის მიხედვით.
ღონისძიების სქემების მიგრაცია: „გაფართოების“ სტრატეგია (add-only) + მარიონეტული გადამყვანები საზღვრებში.

13) ოქმების უსაფრთხოება

Zero Trust: mTLS ყველგან, მოკლევადიანი კრედიტები, მინიმალური შეღავათების პრინციპები.
საიდუმლოებები: კითხვის/ჩაწერის/ადმინისტრირების გასაღებების გამიჯვნა.
გამეორებისგან დაცვა: nonce/დროებითი ფანჯარა ხელმოწერებში; ხელახალი გამოყენების აკრძალვა.
WAF/bot ფილტრები: დაცვა scraping/click frode; დაბალი false positive.
Wendor ზონები: მიკროგენტაცია, ინდივიდუალური VPC/namespace-y, egress-allow-list.

14) ინციდენტები და DR

War-room პროცედურები: გაჩერების ღილაკი დომენებისთვის (შინაარსი/PSP/KYC), RACI, SLA ტრეისის პაკეტისთვის.
DR სკრიპტები: შეყვანის წერტილების აქტივი (Anycast/GSLB), cut-over - 60-90 წმ, კვარტალური სავარჯიშოები.
RCA: შაბლონები დამნაშავეების ძებნის გარეშე, L3-L7 კავშირი, პროტოკოლის აპდიტები/SDK/Runbook.

15) პროტოკოლების წარმატების მეტრიკა

თავსებადობა: პარტნიორების წილი, რომლებმაც გაიარეს Conformance ტესტები; Onboarding დრო (TTO).
საიმედოობა: ინტეგრაციის uptime, p95 API/საბურავები, წარმატებული ვებჰუკების წილი.
უსაფრთხოება: PDN ინციდენტები = 0, გასაღების როტაციის დრო, mTLS ტრაფიკის წილი.
ეკონომიკა: cost per rps/txn/event, Cost-to-Serve- ის შემცირება, მიგრაციის დრო.
პროდუქტი: FTD/ARPU/LTV uplift სტანდარტიზაციიდან (ნაკლები KUS/გადახდების გაჟონვა).

16) ანტი შაბლონები

მოვლენების „თავისუფალი ფორმა“: სქემებისა და ვერსიების არარსებობა - ფანჯრებისა და ანალიტიკოსების გადასასვლელი.
ერთი L7 კარიბჭე N + 1 გარეშე: SPOF და ვიწრო ყელი ვებჰუკებისთვის/PSP.
Retrai გარეშე limits/jitter: ტრაფიკი-ქარიშხალი, ორმაგი გარიგება.
ნედლეული PDn გაცვლაში: ტოკენიზაციის გარეშე/DPIA - მარეგულირებელი რისკები.
ოფსეტური პაგინაცია: გამოტოვება/დუბლიკატები დატვირთვის ქვეშ.
საიდუმლოებები „სამუდამოდ“ და სტატიკური IP კონტროლის გარეშე.
Breaking ცვლილებები პარალელური ფანჯრისა და გადამყვანების გარეშე.

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

1. მიიღეთ API კანონი (ვერსია, idempotence, pagination, შეცდომები).
2. შემოიღეთ Schema Registry და ღერძების/წვეულებების გასაღებების დომენის რუკა.
3. დაავალდებულეთ mTLS + JWS/HMAC S2S და ვებჰუკებისთვის; გასაღების ბრუნვის ავტომატიზაცია/JWKS.
4. კონფიგურაცია limites/retrai/CB/outlier-ejection და per-tenant კვოტები.
5. განათავსეთ ტრეისი/მეტრიკი/ლოგები ერთი 'tracaId- ით "; დაამტკიცეთ SLO ფურცლები.
6. ხელი მოაწერეთ DPA/DPIA- ს, ჩართეთ ტოკენიზაცია და შენახვის/მოცილების პოლიტიკა.
7. შექმენით SDK და conformance ნაკრები; დეპრესიის პოლიტიკის დაფიქსირება.
8. ჩაატარეთ DR/chaos სწავლებები და ომის ოთახი რიტუალები; „შავი დასაწყისი“ მინიმალური ნაკრები.
9. შემოიღეთ ოქმების კატალოგი (პარტნიორის პორტალი): სპეკი, მაგალითები, სიმულატორები, ქვიშის ყუთები.

18) ევოლუციის გზის რუკა

v1 (Foundation): REST/gRPC კანონი, ძირითადი მოვლენების სქემები, ვებჰუკების ხელმოწერები, mTLS.
v2 (ინტეგრაცია): მიგრაციის კონვეიერი, საკომუნიკაციო ტესტები, SDK, რულონის ძრავა კვოტების/რეპრესიებისთვის.
v3 (Automation): SLI, self სერვისის ქვიშის ყუთები/სიმულატორები, ვერსიებს შორის გადამყვანები.
v4 (ქსელის მთავრობა): პროტოკოლების ინტერპარტერული კომიტეტი, ზოგადი SLO/სესხები/ჯარიმები, ერთობლივი PoP/edge პოლიტიკა.

მოკლე რეზიუმე

ურთიერთქმედების ზოგადი ოქმები არის ეკოსისტემის „ენა“: API და ღონისძიებების ერთიანი კონტრაქტები, მკაცრი უსაფრთხოება (mTLS/JWS), იდემპოტენტურობა და მიწოდების გარანტიები, დაკვირვება და SLO, კონტროლირებადი მიგრაცია და DRO. კანონის შემდეგ, მონაწილეები უფრო სწრაფად იბრუნებენ, იშვიათად ეცემა, უფრო ადება და პროგნოზირებს და პროგნოზირებს - კონფიდენტურად იზრდება იურისდიქციის მოთხოვნები.