36 lines
1.7 KiB
Markdown
36 lines
1.7 KiB
Markdown
|
# kmsvc Architecture Clarifications
|
||
|
|
|
||
|
|
## Inter-Pod Message Brokering (Parallel Processing)
|
||
|
|
|
||
|
|
**kmsvc is a distributed, inter-pod SQS-compatible message queue service.** Multiple pods run in parallel sharing the same Kafka cluster and Redis coordination layer.
|
||
|
|
|
||
|
|
### Message Flow
|
||
|
|
```
|
||
|
|
Client Service Pod 1 ----\
|
||
|
|
Client Service Pod 2 ------ gRPC/REST → kmsvc Service (N replicas, stateless)
|
||
|
|
Client Service Pod N ----/ ↓
|
||
|
|
Kafka (3 brokers, KRaft)
|
||
|
|
↓
|
||
|
|
Redis (state coordination)
|
||
|
|
```
|
||
|
|
|
||
|
|
### Key Facts
|
||
|
|
1. **Kafka is the message broker** (durable, distributed) — not in-memory, not per-pod
|
||
|
|
2. **Redis coordinates** in-flight state, dedup, FIFO gating via atomic Lua ops—no leader election
|
||
|
|
3. **Service replicas are stateless** — any replica can handle send/receive/delete
|
||
|
|
4. **Consumer groups** (Kafka native) + Redis low-watermark strategy = at-least-once delivery
|
||
|
|
5. **External services** can:
|
||
|
|
- Call kmsvc gRPC/REST API (REST via ingress-nginx)
|
||
|
|
- Produce/consume Kafka topics directly (same cluster)
|
||
|
|
|
||
|
|
### Design References
|
||
|
|
- `design.md §1`: Architecture diagram
|
||
|
|
- `design.md §2`: API surface (CRD for lifecycle, gRPC/REST for messages)
|
||
|
|
- `design.md §3`: Offset-commit + FIFO gating (inter-pod coordination)
|
||
|
|
- `design.md §9`: Multi-replica scaling (no leader needed)
|
||
|
|
|
||
|
|
### Operational
|
||
|
|
- Horizontal scaling: add more `kmsvc` service replicas—Kafka rebalances automatically
|
||
|
|
- HA: Redis Sentinel/Cluster recommended for production (design.md §9) — currently standalone
|
||
|
|
- Monitoring: Kafka consumer-group lag, Redis pending/inflight keys, visibility timeouts
|