Vraag over de trage service Neem het voorbeeld van het aanmaken van een bestelling. Er is een verzoek naar de service en een antwoord, tussen deze twee acties slaan we de bestelde producten op in de analyse (bijvoorbeeld om de populariteit van producten te tellen). De analyse-service werkt soms langzaam of timeout, en we slagen er niet in om op tijd te antwoorden, waardoor we bestellingen verliezen. Wat te doen om geen bestellingen en dus geld meer te verliezen? Bedenk hoe je de bestelling en analyse kunt paralleliseren.

Чтобы не терять заказы из-за медленной аналитики, нужно отделить обработку заказа от аналитики и сделать их асинхронными.

Пример решения:

1. При создании заказа сервис сразу отвечает клиенту, подтверждая заказ.
2. Информация о заказе отправляется в очередь сообщений (например, Kafka, RabbitMQ).
3. Отдельный сервис или воркер читает сообщения из очереди и обновляет аналитику.

Такой подход позволяет распараллелить обработку и не блокировать основной поток заказа из-за медленной аналитики.

Пример на Go с использованием канала для имитации очереди:

type Order struct {
    ID    string
    Items []string
}

var analyticsChan = make(chan Order, 100)

func createOrder(order Order) {
    // Сразу подтверждаем заказ
    fmt.Println("Order created:", order.ID)
    // Отправляем в аналитику асинхронно
    go func() { analyticsChan <- order }()
}

func analyticsWorker() {
    for order := range analyticsChan {
        // Обработка аналитики
        fmt.Println("Processing analytics for order:", order.ID)
        time.Sleep(time.Second * 2) // имитация медленной работы
    }
}

func main() {
    go analyticsWorker()
    createOrder(Order{ID: "123", Items: []string{"item1", "item2"}})
    time.Sleep(time.Second * 5)
}

Такой подход повышает отказоустойчивость и производительность.