MVP Scope, Tradeoffs, Risks, and Open Questions
MVP Scope
The MVP includes:
- dedicated coordinator server,
- Redis-backed group metadata store with one metadata key per group,
- Redis-backed and memory-backed development state stores,
- group creation API,
- member heartbeat API,
- graceful leave API,
- sticky shard assignment,
- revoke-before-assign,
- member expiration and fencing,
- shard count resharding,
- rollback within a bounded window,
- producer routing metadata API,
- Spring Boot consumer and producer integration,
- optional Redis Stream polling adapter,
- monitoring APIs and coordinator-owned metrics,
- ACL, audit logging, and admin mutation rate limiting,
- Docker and sample pod smoke tests.
Out of Scope for MVP
- Kafka wire protocol compatibility.
- Exactly-once business side effects.
- Global event-id deduplication across shards.
- Embedded coordinator mode inside consumer applications.
- Multi-region active-active coordinator state.
- Automatic Redis Cluster node provisioning.
- A complete hosted control plane.
Tradeoffs
Dedicated Coordinator Server
Benefits:
- Operators can inspect target/current assignment in one place.
- Revoke-before-assign can be enforced centrally.
- Member expiration and fencing are explicit.
- Client logic remains smaller.
Costs:
- The coordinator is an operational dependency.
- The coordinator state store becomes critical infrastructure.
- Coordinator bugs can affect assignment for an entire group.
Admin API as Source of Truth
Benefits:
- Shard count and resharding mutations use one path.
- Member startup YAML cannot accidentally mutate group metadata.
- Operators can audit every metadata mutation.
Costs:
- Operators need authentication and deployment automation around the coordinator API.
- If the coordinator API is unavailable, new mutations and heartbeat reconciliation are delayed.
At-Least-Once Baseline
Benefits:
- Fits Redis Stream consumer group semantics.
- Avoids misleading exactly-once claims for arbitrary business side effects.
- Keeps application ownership clear.
Costs:
- Applications must implement idempotency for duplicate-sensitive side effects.
- Operators must quiesce producers before duplicate-sensitive resharding.
Risks
| Risk | Mitigation |
|---|---|
| Stale owner remains active | Member epoch, assignment epoch, ownership validation, and fencing |
| Rebalance moves too many shards | Sticky assignment and focused tests |
| Redis outage affects control plane | Health checks, runbooks, and clear dependency model |
| State overwrite race | Redis mutex plus store revision checks |
| Resharding duplicates events | Documented producer quiescence requirement |
| Long pending revocations | Metrics, monitoring API, and operational runbook |
| Misconfigured multiple coordinators | Redis mutex and store revision checks serialize group updates |
| Breaking protocol changes | Versioned protocol and compatibility policy |
Open Questions
- Should member IDs always be generated by members, or should the coordinator optionally issue them?
- Should weighted assignment become pluggable after MVP?
- Should metadata updates also write a compact audit/history stream for easier recovery diffing?
- How much built-in DLQ/retry support should the starter provide without taking over application processing policy?
- Which Docker image tags should be published for the first public release?
Current Decisions
- MVP assignment strategy: sticky partition assignment.
- MVP processing guarantee: at-least-once.
- MVP shard count source of truth: coordinator metadata created or changed through Admin API.
- MVP consumer concurrency source of truth: consumer deployment or listener configuration. The coordinator observes resulting logical members through heartbeat.
- MVP coordination safety: Redis metadata key, Redis mutex, and store revision compare-and-set.
- MVP metrics ownership: coordinator metrics only for shared ownership/routing/progress state.