Какую альтернативу Kafka знаешь?

Альтернативы Apache Kafka в 2025

Основные Альтернативы

Я использовал несколько систем для event streaming, кроме Kafka:

1. RabbitMQ (самая популярная альтернатива)

Когда я использовал: в startup-е, когда количество сообщений было <100K/day.

Архитектура

// Producer
@Service
public class OrderEventPublisher {
    @Autowired
    private RabbitTemplate rabbitTemplate;
    
    public void publishOrderCreated(Order order) {
        OrderEvent event = new OrderEvent(order.getId(), "CREATED");
        rabbitTemplate.convertAndSend(
            "orders.exchange",    // Exchange
            "order.created",      // Routing key
            event                 // Message
        );
    }
}

// Consumer
@Component
public class OrderEventListener {
    @RabbitListener(queues = "order.created.queue")
    public void handleOrderCreated(OrderEvent event) {
        System.out.println("Order created: " + event.getId());
        // Обновить кэш, отправить email и т.д.
    }
}

// Конфигурация
@Configuration
public class RabbitConfig {
    @Bean
    public TopicExchange ordersExchange() {
        return new TopicExchange("orders.exchange", true, false);
    }
    
    @Bean
    public Queue orderCreatedQueue() {
        return new Queue("order.created.queue", true);
    }
    
    @Bean
    public Binding binding(Queue queue, TopicExchange exchange) {
        return BindingBuilder.bind(queue)
            .to(exchange)
            .with("order.created");
    }
}

Pros:

• Просто разобраться и запустить
• Flexible routing (Direct, Topic, Fanout exchanges)
• Встроенная очередь с гарантией доставки
• Хороший UI (Management Plugin)

Cons:

• НЕ масштабируется как Kafka (горизонтально ограничена)
• НЕТ встроенного topic replay (история сообщений)
• Высокий overhead на CPU при большых volumes
• Дороже при production scale-up

Когда использовать:

• <1M сообщений/день
• Нужна flexible routing logic
• Приложение small-to-medium
• Not stream processing нужен

---

2. Apache Pulsar (мой фаворит для финтеха)

Когда я использовал: в финтех-компании для обработки платежей в real-time.

// Producer
@Service
public class PaymentEventPublisher {
    @Autowired
    private PulsarTemplate pulsarTemplate;
    
    public void publishPaymentProcessed(Payment payment) {
        pulsarTemplate.sendAsync(
            "persistent://public/default/payment-events",
            payment
        );
    }
}

// Consumer
@Component
public class PaymentEventListener {
    @PulsarListener(subscriptionName = "payment-processor")
    public void handlePaymentEvent(Payment payment) {
        // Обработать платеж
    }
}

// Конфигурация
@Configuration
public class PulsarConfig {
    @Bean
    public PulsarTemplate pulsarTemplate(PulsarClient pulsarClient) {
        return new PulsarTemplate(pulsarClient);
    }
}

Архитектура Pulsar:

Pulsar Topic (persistent://tenant/namespace/topic)
    ├─ Multiple partitions (как Kafka)
    └─ Pulsar Broker (как Kafka broker)
        ├─ BookKeeper (distributed log storage)
        └─ Zookeeper (metadata)

Отличие: отделена storage от serving!
- Broker обрабатывает current requests
- BookKeeper хранит history

Pros:

• Multi-tenancy встроена (разные teams, разные namespaces)
• Geo-replication из коробки (critical для финтеха)
• Message replay по timestamp/message ID
• Better scaling чем Kafka (stateless brokers)
• Sub/Queue modes (как RabbitMQ + как Kafka)
• Tiered storage (recent — fast, old — S3)

Cons:

• Сложнее в освоении чем RabbitMQ
• Меньше примеров чем у Kafka
• Требует BookKeeper (еще один компонент)

Когда использовать:

• Multi-region systems
• Нужна strong geo-replication
• Message history важна (аудит, compliance)
• High throughput + multi-tenancy

---

3. AWS SQS/SNS (когда уже на AWS)

Когда я использовал: в AWS-based компании для микросервисной архитектуры.

SQS (Simple Queue Service)

@Service
public class OrderEventPublisher {
    @Autowired
    private AmazonSQS sqsClient;
    
    public void publishOrderEvent(Order order) {
        String queueUrl = "https://sqs.us-east-1.amazonaws.com/123456789/order-queue";
        
        sqsClient.sendMessage(
            queueUrl,
            new Gson().toJson(order)
        );
    }
}

@Component
public class OrderEventListener {
    @Scheduled(fixedRate = 1000)  // Poll каждую секунду
    public void processMessages() {
        String queueUrl = "https://sqs.us-east-1.amazonaws.com/123456789/order-queue";
        
        ReceiveMessageRequest request = new ReceiveMessageRequest()
            .withQueueUrl(queueUrl)
            .withMaxNumberOfMessages(10)
            .withWaitTimeSeconds(10);  // Long polling
        
        ReceiveMessageResult result = sqsClient.receiveMessage(request);
        
        for (Message msg : result.getMessages()) {
            Order order = new Gson().fromJson(msg.getBody(), Order.class);
            processOrder(order);
            
            sqsClient.deleteMessage(queueUrl, msg.getReceiptHandle());
        }
    }
}

SNS (Simple Notification Service)

// Publisher
@Service
public class OrderEventPublisher {
    @Autowired
    private AmazonSNS snsClient;
    
    public void publishOrderEvent(Order order) {
        String topicArn = "arn:aws:sns:us-east-1:123456789:order-events";
        
        snsClient.publish(
            topicArn,
            new Gson().toJson(order),
            "Order Event"
        );
        // Может быть 0, 1 или 100+ подписчиков
    }
}

Pros:

• Fully managed — не нужно управлять инфрой
• Pay-per-use — дешево при low throughput
• SNS+SQS очень гибко (fan-out pattern)
• VPC integration — secure

Cons:

• Vendor lock-in (AWS specific)
• Message ordering сложнее (SQS FIFO есть, но дороже)
• No replay по историческим сообщениям
• Экспорт данных дорогой

Когда использовать:

• Полностью на AWS
• Small-to-medium throughput
• Хочешь fully managed (не担心 ops)

---

4. Google Pub/Sub (на GCP)

@Service
public class OrderEventPublisher {
    @Autowired
    private PubSubTemplate pubSubTemplate;
    
    public void publishOrderEvent(Order order) {
        pubSubTemplate.publish(
            "order-events",  // Topic
            new Gson().toJson(order)
        );
    }
}

@Component
public class OrderEventListener {
    @PubSubListener("order-events-subscription")
    public void handleOrderEvent(String message) {
        Order order = new Gson().fromJson(message, Order.class);
        processOrder(order);
    }
}

Pros:

• Global scale из коробки
• Serverless (как Lambda)
• Cheap при low-medium throughput

Cons:

• GCP lock-in
• At-least-once delivery (duplicates possible)
• Меньше сообщества чем Kafka

---

5. Redis Streams (для простых случаев)

@Service
public class OrderEventPublisher {
    @Autowired
    private StringRedisTemplate redisTemplate;
    
    public void publishOrderEvent(Order order) {
        redisTemplate.opsForStream()
            .add("orders", Collections.singletonMap("data", order.toString()));
    }
}

@Component
public class OrderEventListener {
    public void consumeOrderEvents() {
        List<MapRecord<String, String, String>> records = 
            redisTemplate.opsForStream()
                .read(StreamReadOptions.empty().count(10), 
                      StreamOffset.fromStart("orders"));
        
        for (MapRecord<String, String, String> record : records) {
            String orderData = record.getValue().get("data");
            processOrder(orderData);
        }
    }
}

Pros:

• Простой setup (уже есть Redis)
• Fast (in-memory)
• Достаточно для event sourcing

Cons:

• Не масштабируется как Kafka/Pulsar
• Memory-based (all data in RAM)
• Нет кластеризации как у enterprise систем

---

Сравнительная Таблица

---

Мой Выбор для Different Scenarios

1. Startup, <100K msg/day: RabbitMQ
2. Financial/Mission-Critical: Pulsar
3. AWS company: SQS/SNS
4. GCP company: Pub/Sub
5. 1M+ msg/day, stream processing: Kafka
6. Just need simple queue: Redis Streams

Интеграция в Java

<!-- Kafka -->
<dependency>
    <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
</dependency>

<!-- RabbitMQ -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

<!-- Pulsar -->
<dependency>
    <groupId>org.apache.pulsar</groupId>
    <artifactId>pulsar-client-spring-boot-starter</artifactId>
</dependency>

<!-- AWS -->
<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>sqs</artifactId>
</dependency>

<!-- Redis -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

Вывод

Нет "лучшей" системы — выбор зависит от:

• Throughput: Kafka для millions/sec, RabbitMQ для thousands/sec
• Geography: Pulsar для multi-region, SQS для single region
• Operations: AWS/GCP managed для "ленивых", self-hosted для контроля
• Бюджет: Fully managed дороже, но меньше ops overhead

Я рекомендую: начать с RabbitMQ, потом мигрировать на Kafka когда нужна масштабируемость или на Pulsar если нужна гео-репликация.