Event and partition design
Align ordering and scale with the business entity whose sequence matters.
- ✓Event naming, ownership and schemas
- ✓Partition-key and ordering analysis
- ✓Topic lifecycle and retention
- ✓Compatibility and schema evolution
Technology Expertise
Kafka Architectures Built Around Delivery Semantics and Ownership
Kafka is an append-only event platform, not a substitute for sound domain design. ARIN helps teams decide what should be an event, how it is partitioned, who owns it, how consumers recover, and how contracts evolve without breaking the ecosystem.
Discuss Your RequirementsReliable processing
Design for at-least-once delivery instead of assuming every message appears once.
- ✓Idempotent consumers and deduplication
- ✓Transactional outbox and change publication
- ✓Retry topics, dead letters and replay
- ✓Consumer lag and rebalance behavior
Operating Kafka
Observe both platform health and business-flow health.
- ✓Broker, partition and consumer metrics
- ✓Lag, throughput and failure alerts
- ✓Correlation and distributed tracing
- ✓Capacity, retention and recovery planning
Frequently Asked Questions
How should a Kafka partition key be selected?
Choose the entity whose events require order and distribute keys well enough for target throughput. Payment, customer or merchant keys produce different ordering and hotspot trade-offs.
What happens when consumers exceed partitions?
Within one consumer group, only one consumer reads a partition at a time, so extra consumers remain idle. Different consumer groups read independently.
How do you recover acknowledged but lost business work?
Use durable publication patterns, idempotent processing, state reconciliation, replay controls and monitoring rather than relying on acknowledgements alone.