Когда бы использовал метод интеграции через очереди?

Когда использовать интеграцию через очереди

Очереди сообщений — один из ключевых паттернов в распределенных системах. Я использовал бы этот подход в следующих сценариях:

1. Асинхронная обработка длительных операций

Если нужно выполнить heavy lifting без блокирования клиента:

// Пример: отправка email после регистрации
@PostMapping("/users")
public ResponseEntity<User> registerUser(@RequestBody UserRequest request) {
    User user = userService.register(request);
    
    // Вместо блокирования на отправке email
    // emailService.sendWelcomeEmail(user); // ПЛОХО
    
    // Публикуем событие в очередь
    messageQueue.publish("user.registered", user);
    
    return ResponseEntity.ok(user);
}

// Асинхронный consumer обработает email
@RabbitListener(queues = "user.registered")
public void handleUserRegistered(User user) {
    emailService.sendWelcomeEmail(user); // Обработается в background
}

2. Слабая связанность между сервисами (Decoupling)

Когда системы должны работать независимо:

// Service A: публикует заказ
public class OrderService {
    @Autowired
    private RabbitTemplate rabbitTemplate;
    
    public void createOrder(Order order) {
        orderRepository.save(order);
        // Service A не знает про Service B
        rabbitTemplate.convertAndSend("orders.created", order);
    }
}

// Service B: обрабатывает инвентарь
public class InventoryService {
    @RabbitListener(queues = "orders.created")
    public void reserveInventory(Order order) {
        inventoryRepository.reserveItems(order);
        // Service B не знает про Service A
    }
}

// Service C: отправляет уведомления
public class NotificationService {
    @RabbitListener(queues = "orders.created")
    public void notifyWarehouse(Order order) {
        messenger.sendToWarehouse(order);
    }
}

3. Обработка пиков нагрузки (Peak Load)

Когда требуется сглаживание трафика:

// API Gateway получает 10000 запросов в секунду
// БД может обработать только 1000
public class AnalyticsController {
    @PostMapping("/events")
    public ResponseEntity<?> trackEvent(@RequestBody Event event) {
        // Быстро добавляем в очередь
        eventQueue.enqueue(event); // ~1ms
        return ResponseEntity.accepted().build();
    }
}

// Consumer обрабатывает со своей скоростью
@Component
public class EventProcessor {
    @Scheduled(fixedDelay = 100)
    public void processEvents() {
        List<Event> batch = eventQueue.dequeueBatch(100);
        // Обработка батча: insert, aggregate, transform
        analyticsService.processBatch(batch);
    }
}

4. Гарантированная доставка сообщений

Когда потеря данных недопустима (financial, healthcare):

// Apache Kafka с persistence
public class PaymentProcessor {
    @Autowired
    private KafkaTemplate<String, Payment> kafkaTemplate;
    
    public void processPayment(Payment payment) {
        // Kafka гарантирует доставку:
        // - Replication на 3 ноды
        // - Acknowledgments: all
        // - Message.timeout.ms для retries
        
        kafkaTemplate.send("payments", payment);
        // Даже если consumer упадет, сообщение останется в Kafka
    }
}

5. Event Sourcing и Event-Driven Architecture

Когда нужна полная история изменений:

// Вместо UPDATE в БД, публикуем события
public class UserProfileService {
    public void updateProfile(Long userId, ProfileUpdate update) {
        User user = userRepository.findById(userId);
        
        // Event sourcing подход
        user.setName(update.getName());
        
        eventBus.publish(new UserProfileUpdatedEvent(
            userId, 
            update.getName(), 
            Instant.now()
        ));
        
        // Из событий можно восстановить исторический state
    }
}

6. Интеграция legacy систем

Когда старые системы не могут напрямую взаимодействовать:

// Adapter pattern с очередями
public class LegacySystemIntegration {
    // Читаем из старой системы, пишем в очередь
    public void pollLegacyData() {
        List<LegacyRecord> records = legacyDatabase.query();
        records.forEach(r -> messageQueue.send("legacy.data", r));
    }
    
    // Новая система потребляет
    @RabbitListener(queues = "legacy.data")
    public void processLegacyRecord(LegacyRecord record) {
        NewSystemEntity entity = transform(record);
        newSystemRepository.save(entity);
    }
}

Когда НЕ использовать очереди

• Синхронные операции: непосредственно нужен результат (validating email)
• Real-time требования: trading systems, online gaming (очередь добавляет latency)
• Простые CRUD операции: если нет асинхронности, очереди усложнят архитектуру
• Слабые консистентность требования: если можно обойтись polling или webhook

Практический выбор между технологиями

В моей практике я выбирал бы Kafka для high-volume распределенных систем, RabbitMQ для более традиционных enterprise систем, и Redis для простых queue сценариев с приемлемыми потерями.