77개 시뮬 시나리오와 4개 목표 빌더, 총 81개 시작점을 카테고리별로 정리했습니다. 카드를 누르면 즉시 로드됩니다.
결제 stream → Kafka → Flink(windowing + stateful, exactly-once)로 이상 패턴 감지. 5,000 event/s · 10초 실측: Payment API 49,834건 → Kafka 49,831건 → Flink x4 49,611건, 성공률 100% · p50 41.1ms. Kafka lag은 220건에서 머문다 — 전달률 3 partition × 5,000 = 15,000/s가 유입 4,983/s의 3배라 쌓일 이유가 없다(lag 220은 흐르는 중인 양이지 밀린 양이 아니다). Flink CPU는 2%뿐인데, 이건 "stateful 스트림이 싸다"가 아니라 이 모델의 Flink 비용 상수가 이벤트당 매우 작기 때문이다. ★ Flink는 이 모델에서 **단말**이다 — 받은 이벤트를 다음 노드로 넘기지 않으므로 뒤에 그려진 Alert Service · Cassandra · Prometheus는 트래픽을 받지 않는다(시각/문서용 배치). 실제 운영에서는 Flink가 alert를 발행하고 history를 쓰지만, 그 경로는 지금 엔진의 스트림 모델 밖이다.
fraud-detection시작 →5,000 req/s — 호출 매칭 조회 40% + driver heartbeat 30% + trip 처리 20% + 수요 이벤트 10%. 10초 실측: Matching(Go geohash) 49,887건 · CPU 60%, Redis GEORADIUS 19,952건(hit 95%), Cassandra 15,172건, Trip Service x4 9,925건 · CPU 44%, CockroachDB 9,926건, Flink 4,817건 — 성공률 100% · p50 63.9ms. Matching은 16대여야 한다: go-http는 event-loop 1 loop라 인스턴스당 상한이 ≈417 RPS이고, 6대(2,500 RPS)였을 때는 절반이 **fd-exhausted 20,732건**으로 죽어 성공률 51.9%였다. ★ Flink(surge pricing)와 Cassandra는 이 모델에서 **단말**이다 — 받은 이벤트를 다음 노드로 넘기지 않으므로 그 뒤로 흐르는 트래픽은 없다(시각/문서용). 그래서 surge는 유입량 4,817건까지만 관측된다. 예전 배선은 Cassandra → Flink였는데 Cassandra도 단말이라 Flink가 한 건도 못 받았다 — 지금은 Matching이 수요 이벤트를 직접 흘린다.
ride-sharing시작 →결제 처리 chain — Kong → Auth → Payment Service → Ledger (append-only Postgres) + Kafka로 Fraud Detection (Flink) 실시간 분석. PCI-DSS / SOX 감사 추적 + 이상 거래 감지.
fintech-ledger시작 →