Сталкивался ли со сложными задачами

Сложные задачи: опыт и решения

Да, я встречал МНОГО сложных задач. Это хорошие истории.

Сложная задача 1: Race Condition в финансовой системе

Проблема: Два одновременных запроса на перевод денег могут привести к потере денег.

Аккаунт A: $1000 Транзакция 1: перевести $500 Транзакция 2: перевести $700

Ожидается:

• Если обработаны последовательно, одна должна fail (недостаточно средств)

Что произошло:

• Обе прошли! A стал = -$200

Корень проблемы: Thread A: SELECT balance → 1000 Thread B: SELECT balance → 1000 Thread A: UPDATE balance = 1000 - 500 = 500 Thread B: UPDATE balance = 1000 - 700 = 300 (НЕПРАВИЛЬНО!)

Решение:

-- Используем SELECT FOR UPDATE SKIP LOCKED
BEGIN;
SELECT balance FROM accounts WHERE id = ? FOR UPDATE;
-- Проверяем
IF balance >= amount THEN
    UPDATE accounts SET balance = balance - amount;
    INSERT INTO transactions...;
    COMMIT;
ELSE
    ROLLBACK;
END;

Результат: Полная финансовая безопасность, 0 потерь.

Сложная задача 2: Разрастающаяся БД (500M+ записей)

Проблема: Query, который выполнялся за 100ms, теперь выполняется за 30 секунд.

Проблема: таблица transactions выросла с 10M до 500M записей.

Диагностика:

EXPLAIN ANALYZE
SELECT * FROM transactions
WHERE user_id = 123
AND created_at > '2024-01-01'
ORDER BY created_at DESC
LIMIT 100;

-- Результат: Seq Scan (скан всех 500M строк!)

Решение 1: Индекс

CREATE INDEX idx_transactions_user_created
ON transactions(user_id, created_at DESC);

Результат: 30 сек → 50ms (600x быстрее)

Решение 2: Партиционирование

ALTER TABLE transactions 
PARTITION BY RANGE (created_at)
(PARTITION 2024_01 VALUES..., PARTITION 2024_02...);

Результат: старые данные в отдельных партициях, scan быстрее

Решение 3: Архивирование

-- Архивируем данные старше 1 года
CREATE TABLE transactions_archive AS
SELECT * FROM transactions WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);

DELETE FROM transactions WHERE created_at < DATE_SUB(NOW(), INTERVAL 1 YEAR);

Результат: Таблица осталась lean, query быстрая.

Сложная задача 3: Memory Leak в production

Проблема: Приложение за неделю потребляет всю памяти (heap grows 2% в день).

Ошибка: OutOfMemoryError after 7 days.

Диагностика:

# 1. Dump heap
jmap -dump:live,format=b,file=heap.bin <pid>

# 2. Анализируем
jhat -J-Xmx4g heap.bin
# Видим: 100M instances String, 90% от них одна и та же строка!

# 3. Ищем в коде
grep -r ""cached_string"" .

# Находим: List<String> cache = new ArrayList<>();
# Добавляем в цикл, но никогда не удаляем!

Решение:

// ДО (leak)
private static List<String> cache = new ArrayList<>();
for (String item : items) {
    cache.add(item); // Растёт бесконечно
}

// ПОСЛЕ (fixed)
private static Map<String, String> cache = 
    new LinkedHashMap<String, String>(16, 0.75f, true) {
        protected boolean removeEldestEntry(Map.Entry eldest) {
            return size() > 10_000; // Max 10K items
        }
    };

// Или лучше: используем Guava Cache
private static LoadingCache<String, String> cache =
    CacheBuilder.newBuilder()
        .expireAfterWrite(10, TimeUnit.MINUTES)
        .build(new CacheLoader<String, String>() { ... });

Результат: Memory stable, 0 memory growth.

Сложная задача 4: Микросервисная архитектура (с race conditions)

Проблема: При распределённой транзакции могут быть inconsistencies.

Пример: Order microservice вызывает Payment service.

Order Service: создаёт Order (status=PENDING) Payment Service: обрабатывает платёж (status=SUCCESS) Но Order Service не видит обновления!

Result: Order stuck в PENDING, хотя платёж успешен.

Решение: Event-Driven + Saga pattern

// Order Service
@Service
public class OrderService {
    @Transactional
    public void createOrder(Order order) {
        // 1. Создаём order
        order.setStatus(OrderStatus.PENDING);
        orderRepository.save(order);
        
        // 2. Публикуем событие
        eventPublisher.publish(new OrderCreatedEvent(order.getId()));
    }
}

// Payment Service
@Component
public class PaymentEventListener {
    @KafkaListener(topics = "order-events")
    public void handleOrderCreated(OrderCreatedEvent event) {
        try {
            // Обрабатываем платёж
            Payment payment = processPayment(event.getOrderId());
            
            // Публикуем результат
            eventPublisher.publish(new PaymentSuccessEvent(event.getOrderId()));
        } catch (Exception e) {
            eventPublisher.publish(new PaymentFailedEvent(event.getOrderId()));
        }
    }
}

// Order Service слушает результат
@Component
public class OrderPaymentListener {
    @KafkaListener(topics = "payment-events")
    public void handlePaymentSuccess(PaymentSuccessEvent event) {
        Order order = orderRepository.findById(event.getOrderId());
        order.setStatus(OrderStatus.CONFIRMED);
        orderRepository.save(order);
    }
    
    public void handlePaymentFailed(PaymentFailedEvent event) {
        Order order = orderRepository.findById(event.getOrderId());
        order.setStatus(OrderStatus.FAILED);
        orderRepository.save(order);
    }
}

Результат: Eventually consistent, нет deadlocks.

Сложная задача 5: Performance bottleneck при 50K RPS

Проблема: API медленнеет при пиковой нагрузке:

• 50K RPS
• Response time: 5-10 seconds (должно быть 100ms)
• CPU: 95% utilization

Диагностика:

# 1. Профилируем
java -XX:+UnlockDiagnosticVMOptions -XX:+DebugNonSafepoints \
     -XX:+TraceClassLoading -jar app.jar

# 2. Видим: 80% времени в database queries
# SELECT * FROM user_profiles WHERE user_id = ?
# Это вызывается 1000+ раз в секунду

# 3. Анализируем план запроса
EXPLAIN ANALYZE ...
# Seq Scan без индекса!

Решение многоуровневое:

1. Индекс

CREATE INDEX idx_user_profiles_user_id ON user_profiles(user_id);

Результат: 5 сек → 500ms

1. Кеширование

@Cacheable(value = "profiles", key = "#userId")
public UserProfile getProfile(Long userId) {
    return repository.findByUserId(userId);
}

Результат: 500ms → 50ms (Redis hit < 1ms)

1. Connection pooling

spring.datasource.hikari.maximum-pool-size: 50

Результат: 50K RPS, 80ms response time, 20% CPU utilization.

Что я вынес из этих задач

1. Debugging skills — умение находить bottlenecks
2. Systemic thinking — вижу whole picture
3. Persistence — не сдаюсь при сложностях
4. Communication — объясняю findings нон-техническим людям
5. Prevention — теперь пишу code, чтобы избежать этих проблем

Главный вывод

Сложные задачи — это не проблемы, это возможности для роста. Каждая решённая проблема делает тебя лучше разработчиком.