메시지 중개 및 이벤트 라우팅

(섹션: 기술 및 인프라)

간략한 요약

메시지 중개인은 iGaming의 기본 통합 및 이벤트 버스 계층입니다. 요율, 지불, 사기 방지, KYC, CRM 및 분석 간의 메시지 전달, 버퍼링 및 라우팅을 구현합니다. 잘 설계된 교환 (교환), 대기열, 라우팅 키 및 재 전달 규칙은 대기 시간이 짧고 트래픽 버스트에 대한 저항력과 예측 가능한 SLO를 제공합니다.

iGaming 플랫폼에서 중개인 역할

디커플링 서비스: 하드 동기식 통화 대신 이벤트 게시.
유연한 라우팅: 하나의 이벤트 → 많은 소비자 (CRM, 위험, 분석).
로드 관리: 대기열, 프리 페치/QoS, 백 프레셔.
신뢰성 및 복구: 확인, 배상, DLQ, 복제.
감사 및 준수: 이벤트 추적, PII 마스킹, 보존 정책.

메시징 모델

Point-to-Point (작업 대기열): 하나의 소비자가 작업을 처리합니다 (KYC, 전자 메일, PSP 웹 후크).
펍/서브 (도메인 이벤트): 여러 대기열에 대한 팬 아웃이있는 교환기에 게시합니다.
중개인을 통한 RPC: 상관 관계가있는 요청/응답 (뜨거운 경로에서는 거의 없지만 통합에 유용함).

라우팅 개념 (AMQP 클래식)

교환 및 바인딩은 메시지가 어떤 대기열에 속할지 결정합니다

1. 'routing _ key' 와 직접 일치합니다.
2. 주제-템플릿 ' b. c 'c "(한 단어) 및' # '(0 + 단어). 보편적 인 선택.
3. 팬 아웃-모든 관련 대기열로 방송합니다.
4. 헤더 - 헤더 라우팅 (키/값), 복잡한 정책에 유용합니다.

키 및 토폴로지의 예:

'지불. psp. 스트라이프. ',' 지불에 성공했습니다. psp.. 실패 ', 베팅. 라이브. # ',' rg. 한계. 위반 '.
도메인 별 교환기: '결제. 주제 ',' 베팅. 주제 ',' 위험. 주제 '; 개인 - '플랫폼' 시스템 이벤트. 감사 '.

권장 사항:

도메인 키 체계를 표준화합니다. 서브 도메인. 동사. 상태 '(뱀	도트 케이스-균일).
연결성을 줄입니다-하나의 교환기 → 많은 대기열, 불필요하게 "많은 교환기" 가 아닙니다.
다중 테넌시의 경우: 클라이언트 당 vhost/네임 스페이스, 키의 접두사: 'tenantX. 지불. psp... '.

대기열 및 정책

작업 대기열: 비즈니스 처리기가 소비합니다.
재시도 대기열: 지수 백업을위한 TTL (지연) 및 DLX (예: '5s → 1m → 5m → 1h').
DLQ (Dead-Letter Queue): 레트라가 고갈 된 후 마지막 "덤프".
우선 순위: 긴급한 작업 (결론> 문자).
게으른/정원: 게으른-큰 잔고가있는 RAM 절약; 정족수 - 합의 기반 HA.

미니 정치인 (개념):

'일. q '→' x-dead-letter-changement = 재 시도. 전자 '
'재 시도. 1m. q '→' x-messation-ttl = 60000 ',' x-dead-letter-changement = work. 전자 '
'dlq. q '→ 모니터링 및 수동 개선

배송 보증 및 절차

최소한 한 번 - 기본값: 중복이 가능합니다 → demempotence가 필수입니다.
최대 한 번에 최소 지연이지만 손실 위험 ("중요하지 않은" 신호).
정확히 한 번-중개인에게는 거의 실용적이지 않습니 더 어렵고 비싸게 달성했습니다. 돈을 위해: 적어도 한 번 + 단단한 dempotence.

주문:

하나의 대기열과 단일 소비자와 함께 주문이 유지됩니다. 병렬 처리 + 복귀로 순서가 방해 될 수 있습니다.
주문 요구 사항이있는 엔티티의 경우 스트림 (키당 단일 활성 소비자) 을 직렬화하거나 "로그" 버스 (스트리밍) 로 전송하십시오.

이념과 거래 출판

메시지의 Idempotency-Key (ULID/UUI), TTL을 사용한 디드 업 스토리지 또는 키로 업저드 됨.
전송 패턴: 비즈니스 트랜잭션 내에서 '아웃 박스' 테이블에 이벤트를 작성하면 커넥터는 "이중 항목 "/손실을 제외합니다.
상관 메타 데이터: 'messation _ id', 'trace _ id', 'causation _ id', 'tenant _ id'.

브로커를 통한 RPC (필요한 경우)

요청은 '응답 _ to' 및 '상관 _ id' 로 게시되며 응답은 지정된 대기열에 있습니다.
제한된 (외부 공급자, 동기 점검), 제어 시간 초과 및 채팅 경향 (그렇지 않으면 분산 모놀리스로 저하) 을 사용하십시오.
핫 사용자 경로의 경우 비동기식 이벤트 + 상태 투영이 선호됩니다.

데이터 계약 및 스키마

형식: Avro/Proto/JSON-Schema. JSON의 경우 버전과 필요한 필드를 수정하십시오.

진화의 정치: 역 호환 변화; 이주없이 변경을 중단하는 것은 금지되어 있습니

PII - 필드의 토큰 화/암호화; 목적과 저장 수명.

오류 처리, 재 트레이, DLQ

분류: 임시 (네트워크/5xx) 리트레이 →; 파일 (검증/체계) → DLQ.
지수 백오프 + 지터, 재 시도 한계, 독약 라벨.
배송 지연: TTL/지연 교환을 통해.
원인을 수정 한 후 DLQ에서 "작동하도록 재 주입" 도구.

관찰 가능성 및 SLO

생산자 지표: 게시 속도, 오류/확인.
대기열 지표: 길이, 소비율, 배송 비율, p99 대기열 시간.
소비자: 지연, 처리량, 처리 시간, NACK 주식.

SLO: 이벤트 전달의 p99 E2E 대기 시간 가용성은 99 이상입니 9%; DLQ- 속도

추적: 엔드 투 엔드 'trace _ id '/' span _ id', 'messation _ id' 로 로그.
경고: DLQ/lags 성장, 쿼럼 하락, NACK 서지, 재 시도 단계 고착.

보안 및 액세스

대중 교통에서의 SL/MTLS; 영구 대기열이 저장될 때 디스크의 암호화.
RBAC/ACL: v양/네임 스페이스/주제별로 권리를 게시/소비합니다.
세분화: 민감한 도메인 (결제/CCM) - 별도의 교환기/클러스터.
Vault/SOPS의 비밀; 출판물/구독에 대한 감사 기록.
데이터 현지화: 지역 별 저장 및 유지 (EU, 터키, LatAm).

높은 가용성 및 DR

정족수 대기열/복제, 홀수 노드, AZ 친 화성 방지.
중요한 도메인에 대한 지역 간 복제 (연합/삽질).
전환 규정 (런북), 주기적 DR 연습 (게임 일).
코드 (IaC) 로 토폴로지 검증-반복 가능한 예금 및 빠른 수지.

성능 및 튜닝

프로듀서: 게시자가 확인, 채널 재사용, 비동기 게시물.
대기열: 작업의 평균 지속 시간 동안 미리 가져옵니다. 깊은 잔고에 대해 게으른; "핫" 큐를 노드별로 분리합니다.
네트워크/OS: 10/25G, 파일 디스크립터, JVM/GC-로드 프로파일.
버스트로드 테스트 (일치, 토너먼트, 최고 지불).

iGaming의 전형적인 라우팅 패턴

1. 결제 이벤트 (주제):

교환: '지불. 토픽 '

키:

'지불. psp. 스트라이프. 성공했다 '
'지불. psp.. 실패 '
'철회. 요청했습니다 #`

소비자 대기열:

'원장. 작가. q '(바인딩:' 지불. #`)
'crm. 트리거. q '(바인딩:' 지불... 성공 ')
'위험. 리뷰. q '(바인드:' 철회. #`)

2. 사기 방지 점수 (직접 + 재 시도):

'위험. 일. q '여러분' 위험. 직접 '(' routing _ key = risk. 확인 ')

'위험. 다시 시도합니 1m. q '(TTL 60 년대 → DLX가 위험으로 돌아 왔습니다. 직접 ')

'위험. dlq. 치명적인 q '.

3. 알림 (fanout + 우선 순위):

'알림. 팬 아웃 '→' 이메일. q (prio) ',' sms. q ',' 푸시. q '

우선 순위: 마케팅 메일보다 결론/제한.

4. 감사 및 추적 (헤더):

헤더 바인딩 '{"테넌트": "X", "크리티컬": "참"}' → 별도의 감사 대기열.

최소 메시지 체계 (JSON) 의 예

json
{
"message_id": "01HX8H8Y6D6W0T1S2A3B4C5D6E",
"trace_id": "f4d2a1...e9",
"occurred_at": "2025-11-05T11:20:45. 321Z",
"tenant_id": "eu-1",
"schema_version": 3,
"event": "payments. psp. stripe. succeeded",
"payload": {
"payment_id": "pay_123",
"player_id": "p_987",
"amount": { "currency": "EUR", "value": 50. 00 },
"psp_tx": "tx_456",
"idempotency_key": "ulid_..."
}
}

다른 루프와의 통합

스트리밍/분석: 재 처리 및 재 처리를 위해 로그 버스 (Kafka/Redpanda) 에서 중요한 주제를 복제 할 수 있습니다.
Fichestor: 이벤트 → 온라인 기능 (Redis) 및 오프라인 파티 (Parquet/OLAP).
사가 오케스트레이션: 직접/주제를 통한 명령, 이벤트-펍/sub; 보상 단계 - 별도의 메시지입니다.

구현 체크리스트

1. 도메인 교환기 및 라우팅 키 표준을 정의하십시오.
2. 각 중요한 흐름에 대한 작업/재 시도/DLQ를 설계하십시오.
3. 게시자를 사용하면 필요한 경우 '미리 가져오기', 우선 순위 및 지연이 확인됩니다.
4. idempotency 키, Outbox 및 상관 ID를 입력하십시오.
5. 데이터 스키마 및 진화 규칙을 승인합니다.

6. 도메인/테넌트 단위로 분류하기

7. SLO 및 알림 설정 (지연, DLQ 속도, p99).
8. DR 계획 및 자동화 된 IaC 토폴로지를 준비하십시오.
9. 로드 및 혼돈 테스트를 수행하십시오.
10. 사건 런북을 문서화하고 DLQ에서 다시 주입하십시오.

반 패턴

핵심 규율이없는 하나의 "거대한" 교환기; 무작위 "필요에 따라" 바인딩.
재 시도/DLQ 부재 및 시간/치명적 오류 혼합.
사용자 핫 경로에서 브로커를 통한 동기식 RPC.
dempotency 및 Outbox → 돈의 두 배/손실.
PII 스토리지를 명확하게 공유하고 모두를 위해 게시/소비하십시오.

요약

잘 설계된 메시지 중개인은 라우팅이 예측 가능하고 내결함성이 토폴로지 수준에 내장되어있는 강력한 이벤트 동맥입니다. 단일 키 표준 인 주제 교환기를 사용하여 각 중요 스트림, demempotency 및 Outbox, 엄격한 SLO 및 관찰 가능성에 대해 작업/재 시도/DLQ를 사용하십시오. 스트리밍 버스 및 상태 프로젝션과 함께 iGaming 플랫폼은 부하가 증가함에 따라 복잡성에 대한 지속적인 속도, 투명성 및 제어를 제공합니다.