Приведи пример сложной задачи с прошлого проекта

Пример сложной задачи с прошлого проекта

На одном из моих проектов мы работали с высоконагруженным API для обработки финансовых транзакций. Система принимала платежи через REST API, и одна из ключевых задач заключалась в обеспечении консистентности данных и отказоустойчивости при параллельной обработке тысяч запросов в минуту.

Проблема и её сложность

Основная проблема была связана с обработкой дублирующих запросов и несинхронизированным состоянием данных. Клиенты иногда отправляли одинаковые транзакции несколько раз из-за проблем в их сетях или логике. Наша система должна была:

• Гарантировать, что дублирующий запрос не создаст две одинаковые транзакции.
• Обеспечить корректное обновление балансов пользователей даже при конкурентных запросах.
• Минимизировать время ответа API, несмотря на необходимость дополнительных проверок.

Сложность заключалась в необходимости соблюдения ACID-принципов в распределённой системе, где база данных была разбита на шарды для повышения производительности. Традиционные транзакции на уровне базы данных не покрывали весь поток из-за использования нескольких сервисов (балансы хранились в одном шарде, история транзакций в другом).

Решение и реализация

Мы разработали стратегию, основанную на идентификаторах запросов (Request ID) и асинхронной проверке через распределённый кэш.

Шаг 1: Введение уникального Request ID Каждый клиентский запрос должен содержать уникальный request_id, генерируемый на стороне клиента (например, комбинация user_id + timestamp + random_suffix).

Шаг 2: Проверка дублирования через Redis При получении запроса система сначала проверяла наличие request_id в Redis (который использовался как распределённый кэш с TTL 30 секунд).

import redis
from fastapi import FastAPI, HTTPException

app = FastAPI()
redis_client = redis.Redis(host='redis-host', port=6379, db=0)

def check_duplicate_request(request_id: str, user_id: int) -> bool:
    cache_key = f"{user_id}:{request_id}"
    # SETNX (Set if Not Exists) — атомарная операция для предотвращения дублирования
    if redis_client.setnx(cache_key, "processing"):
        redis_client.expire(cache_key, 30)
        return False  # Не дублирующий запрос
    else:
        return True  # Дублирующий запрос

Шаг 3: Обработка конкурентности через optimistic locking Для обновления балансов использовали оптимистичную блокировку (optimistic locking) на уровне записи в базу данных:

UPDATE user_balances
SET balance = balance + :amount, version = version + 1
WHERE user_id = :user_id AND version = :current_version;

Если обновление не затрагивало строки (версия изменилась), операция повторялась с новыми данными после небольшой задержки.

Шаг 4: Асинхронное фиксирование транзакции После успешного обновления баланса информация о транзакции отправлялась в очередь сообщений (Kafka) для записи в историю транзакций и другие связанные системы.

def process_transaction(request_data: dict):
    if check_duplicate_request(request_data['request_id'], request_data['user_id']):
        return {"status": "duplicate", "message": "Request already processed"}
    
    # Попытка обновления баланса с optimistic locking
    success = update_user_balance_optimistic(request_data['user_id'], request_data['amount'])
    if not success:
        # Повторная попытка после короткой задержки
        time.sleep(0.1)
        success = update_user_balance_optimistic(request_data['user_id'], request_data['amount'])
    
    if success:
        # Отправка в очередь для асинхронной обработки
        kafka_producer.send('transactions', request_data)
        return {"status": "success", "transaction_id": generate_uuid()}
    else:
        return {"status": "error", "message": "Could not process transaction"}

Тестирование решения

Тестирование этой задачи было комплексным:

1. Нагрузочное тестирование с помощью Locust для имитации тысяч параллельных запросов с одинаковыми request_id.
2. Проверка конкурентности через юнит-тесты, которые запускали несколько потоков, пытающихся изменить баланс одного пользователя.
3. Интеграционные тесты всего потока: от API до записи в Kafka и конечной базы данных.
4. Восстановление после сбоев: тестирование поведения системы при недоступности Redis или одного из шардов базы данных.

Результаты

Решение позволило:

• Сократить количество дублирующих транзакций на 99.8%.
• Удерживать время ответа API ниже 200 мс даже при пиковой нагрузке.
• Обеспечить консистентность данных без использования глобальных транзакций, что было критично для масштабирования системы.

Эта задача стала примером того, как тщательный анализ требований, выбор правильных инструментов (Redis для распределённых проверок, optimistic locking для конкурентности) и многоуровневое тестирование позволяют решать сложные проблемы в высоконагруженных системах.