მიკრო სერვისის არქიტექტურა

1) რატომ არის მიკრო სერვისები iGaming- ში

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

როდესაც არ ღირს: მცირე ბრძანება/მოცულობა, არ არსებობს DevOps პრაქტიკოსი, ტესტების სუსტი ავტომატიზაცია - მაშინ მოდულური მონოლითი უკეთესია.

2) დომენები, საზღვრები და გუნდები (DDD + Team Topologies)

აფეთქების ღუმელის კონტურები: ანგარიში/პროფილი, KUS/Complaence, გადახდები/საფულე, თამაშის შინაარსი/აგრეგაცია, ბონუსები/მისიები, ტურნირები, მარკეტინგი/CRM, ანგარიშები/BI.
Bounded Context = მონაცემთა მოდელის ხელშეკრულება და ენა.
გუნდის ცვლილების ნაკადები: ერთი ბრძანება = ერთი წრე + საკუთარი SLO.
BFF (Backend Frontend): ცალკეული ფასადები Web/Mobile/Partner- ისთვის, რათა არ შეაგროვოს „ორკესტრი“ კლიენტზე.

3) კომუნიკაციები: სინქრონი და ასინქრონი

სინქრონი (REST/gRPC): როდესაც საჭიროა დაუყოვნებელი პასუხი (ანაბრის დროს ლიმიტის გადამოწმება).
ასინქრონი (Kafka/NATS/SQS): მოვლენები და ფონის პროცესები (ფულადი სახსრების დარიცხვა, გაგზავნა, რეიტინგის განახლება).

წესები:

კრიტიკული გზა = მინიმალური ქსელის ჰოპები.
ინტერდისციპლინური ინტეგრაცია - მოვლენებისა და სახელშეკრულებო API- ების საშუალებით.
არ ააწყოთ „5 + სინქრონული ზარის ჯაჭვები“ ინტერნეტით, შეგიძლიათ გამოიყენოთ EDA/საგები.

4) კონტრაქტები და ვერსიები

პირველი კონტრაქტი: OpenAPI/AsyncAPI + Schema Registry (Avro/JSON Schema).
SemVer + თავსებადობა: ველების დამატება არ არღვევს მომხმარებლებს.
Consumer-driven contracts (CDC): CI- ში ავტომობილების შემოწმება (რეგრესიების საწინააღმდეგოდ).
დეპრესიის პოლიტიკა: დამხმარე ფანჯარა (12-18 თვე), ტელემეტრია ძველი ვერსიით.

5) მოვლენები, საგები და თანმიმდევრულობა

Outbox/Transaction Log Tailing: ატომური ჩანაწერი „მონაცემები + მოვლენა“.

საგა შაბლონები:

ორკესტრი (ცენტრალური კოორდინატორი) გადახდების/დასკვნებისთვის.
ქორეოგრაფია (რეაქცია მოვლენებზე) ბონუსების/მისიებისთვის.
Idempotence: გასაღებები 'entityId + action + nonce', dedup რეესტრის შენახვა.
თანმიმდევრულობა: „გარეგანი“ - მოვლენების საშუალებით; „შიდა“ - გარიგებები მომსახურების ფარგლებში.

6) მონაცემები და შენახვა

„საკუთარი ნაკადის“ პრინციპი: თითოეულ სერვისს ფლობს საკუთარი მონაცემთა ბაზა (სქემების იზოლაცია).

წვდომის ნიმუშის საცავის არჩევანი:

გარიგებები/ბალანსები - რელაქსაცია (PostgreSQL) მკაცრი ინვარიანტებით.
მოვლენები/ჟურნალი - append-only (Kafka/Redpanda).
კეში/სესიები - Redis/KeyDB; ლიდერები - Redis Sorted Sets.
ძებნა - OpenSearch/Elastic.
მატერიალიზებული კითხვის პროგნოზები (CQRS) - სწრაფი სიები/მოხსენებები.

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

Timeouts/Retry with jitter/Retry-budget მხოლოდ idempotent ოპერაციებისთვის.
Circuit-breaker/Outlier-ejection სერვისებს შორის.
Bulkhead: ცალკეული აუზები „ხმაურიანი“ აფსიდებისთვის.
Rate limits per-client/route, backpressure (503 + Retry-After).
Dead-letter + poison მესიჯი რიგებში.

8) Observability

ტრეკერი: OpenTelemetry ('trace _ id' კარიბჭის საშუალებით - სერვისები - BD).
მეტრიკა: RPS, p50/p95/p99, error rate 4xx/5xx, saturation (CPU/mem/queue), ბიზნეს მეტრიკა (TTP, TtW).
Logs: სტრუქტურული JSON, შენიღბვა PII/PAN/IBAN, კორელაცია 'trace _ id'.
SLO/ალერტები: მარშრუტი/ფუნქცია (მაგალითად, 'Deposit p95-300 ms', 'success' 98). 5%`).

9) უსაფრთხოება და შესაბამისობა

Zero-Trust: mTLS სერვისი (SPIFFE/SPIRE), მოკლე სერთიფიკატები.
AuthN/Z: OAuth2/JWT (aud/scope/exp), როლების ატრიბუტი.
საიდუმლოებები: KMS/Secrets Manager/Sealed Secrets, გასაღებების როტაცია.
GDPR/მონაცემთა ლოკალიზაცია: რეგიონალური მტევანი, geo-fencing API კარიბჭეზე.
აუდიტი: უცვლელი ჟურნალები (WORM), ადმინისტრაციული მოქმედებების კვალი.

10) განლაგება და გამოშვება

კონტეინერები/K8s: ერთი სერვისი = ერთი deploy; რესურსები/ლიმიტები; PodDisruptionBudget.
CI/CD: linters, unit/contract/integ ტესტები, უსაფრთხოების სკანი, SBOM.
გამოშვებები: canary/blue-green/shadow, სქემების მიგრაცია expand-and-contract- ით.
ავტო სკეიტი: HPA CPU + RPS + p95 + queue-depth; დასაკეცი დასაკეცი.

11) პროდუქტიულობა და ღირებულება

პროფილირება: p95/99 „სერვისებისა და მეთოდების მიხედვით“, flame გრაფიკები.
კეშინგი: read-through/write-through; TTL/მოვლენების ინვალიდობა.
მონაცემთა მოწყობა: ცხელი მონაცემების შენახვა გაანგარიშებასთან ახლოს.
FinOps: დატვირთვის ტვირთი 60-70%, „warm pools“, არააქტიური მძღოლების ავტომობილი-პაუზა.

12) დომენის შაბლონები (iGaming)

12. 1 გადახდა/საფულე

სერვისები: 'payments-gw' (ფასადი), 'wallet', 'psp-adapters-', 'fraud-check'.
ნაკადი: 'init-reserve' capture/rollback '(საგა).
События: `PaymentInitiated`, `PaymentAuthorized`, `PaymentSettled/Failed`.
Idempotence: 'Idempotency-Key', დედაპლატი 'wallet'.

12. 2 KUS/Complaence

Сервисы: `kyc-flow`, `doc-storage`, `sanctions-check`, `pep-screening`.
События: `KycSubmitted/Approved/Rejected`, `RiskScoreUpdated`.
აუდიტი და ETA: დავალებების რიგები, დროის ხაზის შემთხვევა, ფოსტის მოქმედებები.

12. 3 პრემია/მისიები

სერვისები: 'bonus ძრავა', 'wallet-bonus', 'eligibility'.
ქორეოგრაფია: 'BetPlaced - BonusEngine - BonusGranted - WalletCredited'.
ბოროტად გამოყენებისგან დაცვა: პირადული გრანტები, ლიმიტები, წესების სიმულატორი.

12. 4 ტურნირები/ლიდერები

სერვისები: 'tournament-svc', 'scoring', 'leaderboard'.
შენახვა: Redis ZSET + პერიოდული „გამონადენი“ OLAP- ში.
События: `ScoreUpdated`, `TournamentClosed`, `RewardIssued`.

13) მაგალითი „კონტრაქტი + მოვლენა“ (გამარტივებული)

OpenAPI (ფრაგმენტი) - Wallet

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI (ფრაგმენტი) - მოვლენა

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14) ტესტირება

Unit/Property-based დომენის წესებისთვის.
CDC (Pact/Assertible) - პროვაიდერების/მომხმარებლების კონტრაქტის ტესტები.
ინტეგრაცია ადგილობრივ ბროკერებთან (Testcontainers).
კრიტიკული flows E2E (რეგისტრაცია - ანაბარი, თამაშის დაწყება, დასკვნა).
Chaos/Failover ტესტები: PSP გამორთვა/ბროკერის ვარდნა/ზონის დაკარგვა.

15) მეტრიკა და SLO (მინიმალური)

სერვისების ხელმისაწვდომობა: '99. 9% 'გადახდის/საფულისთვის.
Latency p95: API კრიტიკული გზა 300-500 ms.
Error budget: 0. 1–0. 5% კვარტალში, ბურნ-ალერტები.
რიგები: lead time მოვლენა (produce - consume), DLQ-0. 1%.
ბიზნესი: TTP, TtW, FTD-success, KYC-TtV.

16) ჩეკის ფურცლები

მომსახურების დიზაინი

მკაფიო დომენის საზღვარი და მონაცემთა მფლობელი.
OpenAPI/AsyncAPI + სქემები Registry- ში.
SLO/ალერტები განისაზღვრება; მეტრიკა/ტრეისი/ლოგები ინტეგრირებულია.
Taymaut- ის/Retrais/idempotents- ის პოლიტიკა.
სქემების მიგრაცია: გამოცდა და კონტრაქტი.

გამოსვლამდე

Unit/CDC/ინტეგრაციის ტესტები მწვანეა.
კანარის მარშრუტი და დაბრუნების გეგმა.
წონის მარშრუტები.
საიდუმლოებები/გასაღებები/სერთიფიკატები ვრცელდება.
მომზადებულია Fich Flages და Follbacks.

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

ქსელი მონაცემთა ავტობუსს ჰგავს: მოვლენების ნაცვლად ღრმა სინქრონული ჯაჭვები.
საერთო „ღმერთი“ - BD ყველა მომსახურებისთვის.
იდემპოტენტურობის არარსებობა - ორმაგი ჩამოწერა/დარიცხვა.
მუქი გამოშვებები ტელემეტრიის და კილ-სვიჩის გარეშე.
ფარული სესია (წებოვანი გარეგნობის ნაცვლად ყველგან).
კოდის კონტრაქტები ვერსიის გარეშე და CDC.
ლოგიკა API კარიბჭეში სერვისების ნაცვლად (კარიბჭე = თხელი).

18) მიგრაცია მონოლითიდან (Strangler Fig)

1. განასხვავეთ ფასადის კარიბჭე და პირველი წრე (მაგალითად, გადახდა).
2. ამოიღეთ ორობითი ლოგიკა (outbox) მონოლითიდან მოვლენამდე.
3. თანდათანობით გადაიტანეთ ენდოინები ახალ სერვისზე (მარშრუტიზაცია/კანარის წონა).
4. შეკუმშეთ მონოლითი „ბირთვამდე“ და გამორთეთ.

19) სტეკი და ინფრასტრუქტურა (მაგალითი)

კომუნიკაციები: REST/gRPC, Kafka/NATS; Schema Registry.
საცავი: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP — ClickHouse/BigQuery.
კონტეინერები/ორკესტრი: Docker, Kubernetes (Ingress/Gateway), Service Mesh (Istio/Linkerd) საჭიროების შემთხვევაში.
კარიბჭე: Envoy/Kong/Traefik/NGINX.
CI/CD: GitHub Actions/GitLab CI + ArgoCD/Flux; Pact/OWASP/ZAP.
Observability: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki.

20) საბოლოო ყალბი ფურცელი

შეიმუშავეთ საზღვრები დომენებისა და მონაცემების პასუხისმგებლობის შესახებ.
სინქრონი - მხოლოდ იქ, სადაც ახლა საჭიროა პასუხი; დანარჩენი მოვლენაა.
კონტრაქტები/სქემები/CDC - რეგრესიის დაზღვევა.
საგები + outbox + idempotence - საიმედოობის საფუძველი.
დაკვირვება და SLO არ არის ვარიანტი, არამედ კრიტერიუმი მზად არის.
გამოშვებები კანარის/ცისფერი-მწვანე, მიგრაციის საშუალებით - სწრაფი და კონტრაქტით.
უსაფრთხოება/შესაბამისობა: mTLS, JWT, KMS, რეგიონალური მონაცემები.
ჯერ მოდულური მონოლითი, შემდეგ ევოლუცია - თუ მასშტაბები და გუნდი მზად არის.

მიკრო სერვისის არქიტექტურა

AsyncAPI (ფრაგმენტი) - მოვლენა

გამოსვლამდე

დაგვიკავშირდით

სწრაფი კავშირი

ვიდეო მალე განახლდება

ჩვენ ახლა ძალიან დაკავებული ვართ პროექტებით