მონაწილეთა ურთიერთქმედების ნიმუშები

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

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

ეკოსისტემას აქვს მრავალი მსახიობი (ოპერატორები, პროვაიდერები, გადახდის და KYC სერვისები, აფილატები, მარეგულირებლები, საზოგადოებები, დეველოპერები). „ურთიერთქმედების ნიმუშები“ არის ფასეულობებისა და მონაცემების გაცვლის სტაბილური გზები, რომლებიც უზრუნველყოფენ თავსებადობას, უსაფრთხოებას, ეკონომიკურ ეფექტურობას და მასშტაბურობას.

• შეამცირეთ გარიგების ხარჯები და ინტეგრაციის დრო.
• ინტერკულტურული ნაკადების საიმედოობის გაზრდა და დაკვირვება.
• დაბალანსება სიჩქარე (ლატენტობა) და თანმიმდევრულობა (თანმიმდევრულობა).
• შეიყვანეთ შესაბამისობა და ეკონომიკური სტიმულები ურთიერთქმედების ოქმებში.

2) მონაწილეთა ტაქსონომია და როლები

ოპერატორები/ტენანტები: საბოლოო მომსახურება მომხმარებლებისთვის, ფლობენ ონბორდინგს და UX.
პროვაიდერები/სტუდიები/შინაარსის კვანძები: ისინი უზრუნველყოფენ კატალოგებს/API/ტირიფებს, SLA გამოსაცემად.
გადახდის/რისკის სერვისები: ავტორიზაცია, კლირინგი, ცარჯბეკი, მორიელი, ლიმიტები.
პარტნიორები/აფფილიატები: ისინი უზრუნველყოფენ ტრაფიკს, წარმოქმნიან კონვერტაციის ვებჰუკებს, იღებენ მოხსენებებს.
რეგულატორები/აუდიტი: საჭიროა ჟურნალები, ანგარიშგებები, მონაცემების ლოკალიზაცია.
საზოგადოება/დეველოპერები: გააფართოეთ SDK, შექმნათ პროგრამები/ბოტები/ინტეგრაცია.

3) საკომუნიკაციო არხები და ტრანსპორტი

სინქრონული მოთხოვნები: REST/gRPC RQ/RS, WebSockets/SSE ცოცხალი მოვლენებისთვის.
ასინქრონული საბურავები: Kafka/AMQP/ნაკადის სერვისები, Pub/Sub დომენის მოვლენებისთვის.
ვებჰუკი: გარე პარტნიორის პრეს არხი (აუცილებელია: ხელმოწერა, ტაიმაუტები, რეტრაები).
ფაილური/batch ინტერფეისები: NACHA/CSV/Parquet საანგარიშო და backfill.
Edge/PoP: ქეშირება, WAF, rate-limits, ხელმოწერის შესაბამისობა, ლატენტობის შემცირება.

4) ძირითადი ურთიერთქმედებები (პროტოკოლის დონის ნიმუშები)

1. Request/Response (RQ/RS)

გამოიყენეთ „ახლა გადაწყვეტილებებისთვის“: გადახდის ავტორიზაცია, ლიმიტების შემოწმება, კონფიგურაცია.
ტექნიკა: tamauts, circuit-breaker, retries ერთად ჯიტერი, idempotent გასაღებები.

2. Publish/Subscribe (Event-driven)

ფაქტების გასავრცელებლად: „გარიგება დასრულდა“, „ბალანსი შეიცვალა“, „თამაშის მოვლენა“.
ტექნიკა: საკვანძო ნაწილიზაცია (user _ id/tenant _ id მიხედვით), მესიჯი-ქეის დედაპლატი, ჟურნალის გრძელი შენახვა.

3. Command/Reply (ასინქრონული გუნდები)

ბრძანება „გააკეთე“ დაგვიანებული პასუხით/კორელაციით კორელაციით _ id.
ტექნიკა: გარე შაბლონი, გარანტირებული პუბლიკაცია, კომპენსაციის გუნდები.

4. Webhook Callback

პარტნიორული შეტყობინებების მიღება ხელახლა მიწოდებით (at-least-once).
ტექნიკა: მოთხოვნის ხელმოწერა, timestamp + ანტი-replay, მიმღების იდემპოტენტობა.

5. Batch/Delta Sync

ღამის დახურვები, მოხსენებები, საცნობარო წიგნების განმეორებითი სინქრონიზაცია.
ტექნიკა: Snaphots + Express, საკონტროლო თანხები, ვერსიის სქემები.

5) პროცესების კოორდინაცია: ორკესტრი vs ქორეოგრაფია

ქორეოგრაფია (მოვლენა): მონაწილეები რეაგირებენ აფეთქების ღუმელის მოვლენებზე ცენტრალური კოორდინატორის გარეშე.

დადებითი: სუსტი კავშირი, მასშტაბურობა. უარყოფითი: კვალი/ინციდენტები უფრო რთულია.
ორკესტრი (საგა): კოორდინატორი აკონტროლებს ნაბიჯებსა და კომპენსაციას.

დადებითი: გამჭვირვალე კონტროლი, პროგნოზირება. უარყოფითი: ლოგიკის კონცენტრაციის წერტილი.

საგა (კომპენსაციის გარიგებები): ნაბიჯების თანმიმდევრობა შექცევადი მოქმედებებით, წარუმატებლობის შემთხვევაში. ფინანსების/ბალანსებისთვის სასურველია მკაცრი ლიდერი და კომპენსაციის ოპერაციების მინიმიზაცია.

6) თანმიმდევრულობა და მონაცემები

Strong: გადახდები, ლიმიტები, KYC სტატუსები (ერთი ლიდერი, write-through, სინქრონიზებული ინვარიანტები).
Eventual/Timeline: ტელემეტრია, კატალოგები, მარკეტინგული მოვლენები (ასინქრონული რეპლიკაცია).
CRDT/ვერსია: იშვიათი კონფლიქტებისთვის მრავალ სამაგისტრო სცენარში.
Outbox/CDC: ისე, რომ მოვლენა „ყოველთვის“ გამოქვეყნდეს BD- ში ჩაწერასთან ერთად.
იდენტიფიკატორები: გლობალური, დალაგებული (ULID/KSUID), რეგიონალური დიაგნოზის პრეფიქსი.

7) საიმედოობა და სტაბილურობა

Idempotence: გასაღები მოთხოვნის/კომუნიკაციის დონეზე, მიმღების დედაპლატი.
Retrai: ექსპონენციალური backoff ერთად ჯიტერი; ოპერაციის სიცოცხლის ხანგრძლივობის შეზღუდვა.
ტაიმაუტები და შეფერხების ბიუჯეტი: p95/p99 კრიტიკული მარშრუტებისთვის.
Backpressure: პარალელიზმის შეზღუდვა, რიგები, პრიორიტეტი.
Degrade modes: ნაწილობრივი ფუნქციონირება უარის თქმის დროს (ქეში, გადავადებული ოპერაციები).
Chaos/GameDays: რეგულარული წვრთნები ინტეგრაციისა და არხების გაუმართაობის იმიტაციით.

8) უსაფრთხოება, ნდობა, შესაბამისობა

ავთენტიფიკაცია/ავტორიზაცია: OAuth2/OIDC, mTLS for S2S, ხანმოკლე ნიშნები.
შეტყობინებების/ვებჰუკების ხელმოწერა: HMAC + timestamp + nonce.
კონფიდენციალურობა/ლოკალიზაცია: PII/PCI რეგიონის „ნდობის ზონაში“, ღონისძიებებში მონაცემთა ველის შემცირება (მონაცემები).
აუდიტი და უცვლელი ლოგოები: trace _ id კორელაცია, მიწოდების/კითხვის მტკიცებულებების შენახვა.
საიდუმლოებები და გასაღებები: KMS per-region, როტაცია, პოლიტიკა-as-code.
ანტიფროდი და რისკი: შესასვლელი მორიელი, მონაწილის/არხის ლიმიტები, ქცევითი სიგნალები.

9) ურთიერთქმედებისა და სტიმულის ეკონომიკა

მონეტიზაციის კონტრაქტები: RevShare/Royalti, API (tiered) ტარიფები, ჯარიმები/საკრედიტო ნოტები SLA- სთვის.
Fair use: კვოტები, rate-limits, პარტნიორობის პრიორიტეტი.
Cost-aware routing: თუ რამდენიმე მიმწოდებელი ექვივალენტურია SLA- სთვის, აირჩიოთ უფრო ეკონომიური.
გამჭვირვალე ანგარიშგებები: მიწოდების სტატუსები, მოხმარების საშრობები, შეზღუდული შესაძლებლობების მომსახურება.

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

ტრეკები: trace _ id/spank _ id RQ/RS და მოვლენები.
მეტრიკა: latency p50/p95/p99, error rate, რიგების ლაქი, ქეში ჰიტების წილი, egress.
Logs: სტრუქტურირებული, tenant _ id/partner _ id/region/release.
ალერტინგი: SLO პერ არხი და ინტეგრაცია; ბიზნეს გავლენის პრიორიტეტი (მაგ., გადახდები> ტელემეტრია).

11) სტანდარტული კონტრაქტების შაბლონები

1. REST/gRPC კონტრაქტი:

SemVer ვერსია, სავალდებულო ველები: idempotency-key, request-id, trace-context.
პასუხები: დეტერმინისტული შეცდომის კოდები, retry-hints, ასინქრონული ოპერაციის სტატუსზე.

2. ღონისძიების ხელშეკრულება:

Поля: event_id, occurred_at, producer, subject_id, version, schema_ref.
გარანტიები: ერთხელ მაინც, საკვანძო მხარე, TTL/retention.

3. Webhook კონტრაქტი:

სათაურები: signature, timestamp, nonce, delivery-id.
ქცევა: 2xx = დადასტურება; retrais backoff- დან N საათამდე, მიმღებზე idempotence.

12) პარტნიორების ონბორდის ნიმუშები

ქვიშის ყუთები და ტესტის გასაღებები, API/Events- ის საჯარო კატალოგი, Postman/SDK, მაგალითები.
Self სერვისის პორტალი: ვებჰუკების შექმნა, ღონისძიების ფილტრების კონფიგურაცია, მიწოდების ლოგოების ნახვა.
ჩამონტაჟებული გვარდიის რეილები: ნაგულისხმევი ლიმიტები, გაფრთხილებები საგზაო გრადუსამდე.
ინტეგრაციის სერტიფიკაცია: შემოწმების ფურცლები, კონტრაქტების ავტოსადგურები, სტატუსის „ბაზარი“.

13) რისკები და ანტი-ნიმუშები

სინქრონული „დომინოს ჯაჭვი“: გრძელი RPC სხვის სისტემებზე - კასკადის ფეილები.
იდემპოტენტურობის არარსებობა: ორმაგი გადახდა/მოვლენა.
სქემები ვერსიის გარეშე: მომხმარებლები იშლება გამოშვებების დროს.
გლობალური „სამაგისტრო სიმართლე“ მთელი დომენისთვის: ძვირადღირებული/მყიფე ინტერრეგიონალური თანმიმდევრულობა.
გაუმჭვირვალე ეკონომიკა: პარტნიორები ვერ ხედავენ მოხმარებას, კონფლიქტებსა და უნდობლობას.

14) ურთიერთქმედების მეტრიკა

მოვლენების მიწოდების წარმატება (%) და საშუალო გზა.
p95/p99 შეფერხებები კრიტიკულ მარშრუტებზე (გადახდა, შედეგების გაანგარიშება).
4xx/5xx შეცდომები ინტეგრაციის/არხის, MTTR ინციდენტების შესახებ.
იდემპოტენტურად დამუშავებული დუბლების წილი, ქეშის ჰიტების დონე.
ღირებულება 1k მოთხოვნით/ივენტებით და პარტნიორებით.
პარტნიორების ონბორდის კონვერტაცია: დრო „კეი-პირველი-success“.

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

1. კლასიფიკაცია ურთიერთქმედებები: სინქრონული ღონისძიება, თანმიმდევრულობის კრიტიკა.
2. განსაზღვრეთ SLO და Timauts, ჩართეთ circuit-breakers და backoff.
3. შეიყვანეთ idempotence ყველგან (გასაღებები, დედაპლატი, რეპლეისი).
4. შეადგინეთ სქემების/კონტრაქტების ვერსიები და „expand-migrate-contract“ პოლიტიკა.
5. ჩართეთ ხელმოწერები და ანტი-replay ვებჰუკებისთვის, KMS per-region.
6. ააშენეთ დაკვირვება და სასწრაფო სამსახურის პორტალები.
7. ავტომატიზაცია გაუწიეთ პარტნიორების სერტიფიკაციას და კონტრაქტების ტესტებს.
8. ააშენეთ ეკონომიკა: კვოტები, ლიმიტები, ანგარიშგებები, cost-aware როუტინგი.
9. რეგულარულად ჩაატარეთ GameDays ინტეგრაციისთვის (არხების დეგრადაცია, მასობრივი ჭიდაობა).
10. გადახედეთ დომენის მატრიქსს კვარტალში ერთხელ: სად გავაძლიეროთ strong, სად შეასუსტოთ.

16) FAQ

რა უნდა აირჩიოთ: ორკესტრი თუ ქორეოგრაფია? რთული და კრიტიკული პროცესებისთვის - ორკესტრი; ფართო მასშტაბისთვის - ქორეოგრაფია მკაფიო კონტრაქტებით.
რა უნდა გავაკეთოთ, რომ თავიდან ავიცილოთ „დუბლი“? Idempotent გასაღებები + დედაპლატი მიმღები + მომხმარებლებზე „exactly-once-like“ ლოგიკა.
როგორ დავაჩქაროთ პარტნიორების ონბორინგი? ქვიშის ყუთი, მზა SDK/მაგალითი სკრიპტები, ვებჰუკების ავტომატური შემოწმება და სტატუსის გვერდები.
როგორ ავაშენოთ შესაბამისობა? მინიმუმამდე დაიყვანეთ PII ველები მოვლენებში, შეინახეთ ძირითადი ოპერაციები „ნდობის ზონებში“, ჩაატარეთ უცვლელი აუდიტი.

რეზიუმე: ურთიერთქმედების ნიმუშები არა მხოლოდ ოქმებია, არამედ ეკონომიკური სტიმულირების ერთობლიობაა, მცველი რაილები და დაკვირვება. გააფორმეთ კონტრაქტები, გაუზიარეთ თანმიმდევრულობის დომენები, გააკეთეთ idempotence და „ნაგულისხმევი“, მიეცით პარტნიორებს გამჭვირვალე ინსტრუმენტები და მეტრიკა - და ეკოსისტემა გაიზრდება სტაბილურად და პროგნოზირებად.