Зачем нужна идемпотентность?

Идемпотентность: зачем она нужна

Идемпотентность — это свойство операции, при котором многократное выполнение с одинаковыми параметрами дает один и тот же результат, что и однократное выполнение. В распределённых системах это критически важно.

Почему идемпотентность нужна

1. Надёжность при сетевых сбоях Если клиент не получил ответ от сервера, он переотправит запрос. При идемпотентности повторная отправка безопасна:

// Идемпотентная операция
GET /api/users/123 — можно вызвать 100 раз, результат неизменен

// Неидемпотентная операция
POST /api/accounts — повторный вызов создаст второй счёт

2. Обработка дублей при асинхронной обработке В системах с очередями сообщения иногда обрабатываются дважды:

public class TransferService {
    // ❌ Неидемпотентно
    public void transfer(String txId, BigDecimal amount) {
        // При повторной обработке переведёт деньги дважды
        account.withdraw(amount);
    }
    
    // ✅ Идемпотентно
    public void transfer(String txId, BigDecimal amount) {
        if (transactionDao.exists(txId)) {
            return; // Уже обработано
        }
        account.withdraw(amount);
        transactionDao.save(txId);
    }
}

3. Гарантии в распределённых транзакциях При использовании pattern Idempotency Key:

@PostMapping("/payments")
public ResponseEntity<PaymentResponse> createPayment(
    @RequestHeader("Idempotency-Key") String idempotencyKey,
    @RequestBody PaymentRequest request) {
    
    // Проверяем, не обработан ли этот ключ ранее
    Optional<Payment> existing = paymentRepo.findByIdempotencyKey(idempotencyKey);
    if (existing.isPresent()) {
        return ResponseEntity.ok(toResponse(existing.get()));
    }
    
    // Обрабатываем новый платёж
    Payment payment = processPayment(request);
    payment.setIdempotencyKey(idempotencyKey);
    paymentRepo.save(payment);
    
    return ResponseEntity.ok(toResponse(payment));
}

4. REST API методы и их идемпотентность

GET    /resource/{id}        — ✅ идемпотентен
POST   /resource             — ❌ не идемпотентен (создаёт новый)
PUT    /resource/{id}        — ✅ идемпотентен (заменяет полностью)
PATCH  /resource/{id}        — ⚠️ может быть неидемпотентным
DELETE /resource/{id}        — ✅ идемпотентен (удаление второй раз = 404)

Как обеспечить идемпотентность

1. Уникальные идентификаторы запроса

public class IdempotentRequestHandler {
    private final ConcurrentHashMap<String, CachedResponse> cache = 
        new ConcurrentHashMap<>();
    
    public <T> T handle(String requestId, Function<Void, T> operation) {
        return cache.computeIfAbsent(requestId, key -> {
            T result = operation.apply(null);
            return new CachedResponse(result);
        }).getResult();
    }
}

2. Проверка состояния перед операцией

public void confirmOrder(String orderId) {
    Order order = orderRepo.findById(orderId).orElseThrow();
    
    if (order.getStatus() == OrderStatus.CONFIRMED) {
        return; // Уже подтверждён
    }
    
    order.setStatus(OrderStatus.CONFIRMED);
    orderRepo.save(order);
}

3. Использование БД коснструкций

-- Уникальное ограничение для идемпотентности
ALTER TABLE transactions 
ADD CONSTRAINT unique_transaction_id UNIQUE (external_transaction_id);

-- Вставка только если не существует
INSERT INTO transactions (external_id, amount, status) 
VALUES (?, ?, ?) 
ON CONFLICT (external_id) DO NOTHING;

Последствия игнорирования идемпотентности

• Финансовые потери: двойные платежи
• Data integrity: дублирование записей
• Рассинхронизация: несогласованное состояние
• Сложность отладки: трудно воспроизвести проблему

Идемпотентность — это не опция в микросервисной архитектуре, а обязательное требование для надёжности системы.