В чем плюсы и минусы синхронного общения

Плюсы и минусы синхронного общения

Синхронное общение (Synchronous Communication)

Это когда один сервис отправляет запрос другому и ждет ответ. Используется REST API, gRPC.

ПЛЮСЫ синхронного общения

1. Простота реализации и отладки

Легко отследить ошибки - результат видно сразу:

@PostMapping("/orders")
public OrderResponse createOrder(@RequestBody OrderRequest request) {
    PaymentResponse payment = paymentService.processPayment(request.getAmount());
    if (payment.isSuccess()) {
        return new OrderResponse("Order created", payment.getId());
    } else {
        return new OrderResponse("Payment failed", null);
    }
}

2. Немедленная обратная связь

Клиент сразу получает результат.

3. Гарантированная доставка ответа

Если сервис ответил, операция произошла.

4. Упрощение логики

Нет нужды отслеживать асинхронные состояния.

5. Консистентность данных в реальном времени

Всегда работаем с актуальными данными.

МИНУСЫ синхронного общения

1. Снижение масштабируемости

Темпус ограничена скоростью самого медленного сервиса:

@GetMapping("/user/{id}")
public UserResponse getUser(@PathVariable int id) {
    User user = userService.getUser(id);           // 50ms
    Profile profile = profileService.getProfile(id); // 100ms
    Settings settings = settingsService.getSettings(id); // 75ms
    Notifications notif = notificationService.getNotifications(id); // 200ms
    
    // ИТОГО: 200ms+ плюс сетевые задержки
    return new UserResponse(user, profile, settings, notif);
}

2. Связанность сервисов (Coupling)

Сервисы жестко зависят друг от друга:

public class OrderService {
    private PaymentService paymentService;
    
    public void createOrder(Order order) {
        PaymentResponse payment = paymentService.processPayment(order);
        // Если PaymentService упадет - упадет и OrderService
    }
}

3. Проблема каскадного отказа (Cascading Failures)

Если один сервис упадет, может упасть весь стек.

4. Требует retry логики и обработки таймаутов

public PaymentResponse processPayment(BigDecimal amount) {
    RetryPolicy<PaymentResponse> policy = RetryPolicy.<PaymentResponse>
        builder()
        .withMaxRetries(3)
        .withDelay(Duration.ofSeconds(1))
        .build();
    
    try {
        return Failsafe.with(policy)
            .get(() -> externalPaymentGateway.charge(amount));
    } catch (TimeoutException e) {
        return new PaymentResponse(false, "Timeout");
    }
}

5. Проблемы с распределенными транзакциями

Сложно гарантировать ACID при вызове нескольких сервисов:

public void transferFunds(int fromAccount, int toAccount, BigDecimal amount) {
    accountService.withdraw(fromAccount, amount);
    // Если сервис упал - данные несогласованные
    accountService.deposit(toAccount, amount);
}

6. Снижение пропускной способности

Одновременных запросов ограничено потоками. Каждый синхронный вызов блокирует поток.

7. Сложность тестирования

Нужно мокировать все зависимые сервисы, много boilerplate кода.

Сравнение синхронного и асинхронного

Когда использовать синхронное общение

// Критичные операции с немедленным результатом
@PostMapping("/pay")
public PaymentResponse payment(PaymentRequest req) {
    return paymentService.charge(req);
}

// Простые запросы с низкой нагрузкой
@GetMapping("/status")
public StatusResponse getStatus() {
    return new StatusResponse("OK");
}

// Strong consistency требуется
@PostMapping("/transfer")
public void transfer(TransferRequest req) {
    // Транзакция должна быть ACID
}

Вывод

Синхронное общение просто в реализации и дает немедленную обратную связь, но снижает масштабируемость, создает связанность сервисов и уязвимо к каскадным отказам. Выбор зависит от требований системы и критичности компонента.