Принимал ли сложные решения

Сложные архитектурные решения в практике

Кейс 1: Миграция с monolithic на микросервисную архитектуру

В одном из проектов столкнулся с критической проблемой масштабируемости. Monolithic приложение (Spring Boot + PostgreSQL) обслуживало 100K+ пользователей одновременно, но:

• Деплой всего приложения занимал 15 минут
• One-click deployment зависал все сервисы при любой ошибке
• БД слабо масштабировалась горизонтально
• Разные части приложения требовали разных технологий

Принятое решение: Service-Oriented Architecture

Вариант 1: Медленная миграция через strangler pattern

// Старый monolithic приложение
@RestController
@RequestMapping("/api/v1")
public class UserController {
    @Autowired
    private UserService userService;
    
    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        // Все ещё в monolith
        return userService.findById(id);
    }
}

// Новый микросервис (отдельное приложение)
@SpringBootApplication
public class UserMicroservice {
    // Независимая БД, развёртывание, масштабирование
}

// API Gateway перенаправляет запросы
@Component
public class ApiGateway {
    @Bean
    public RouteLocator customRouteLocator(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("user-service", r -> r
                .path("/api/v1/users/**")
                .uri("http://user-microservice:8081")) // Новый сервис
            .route("legacy", r -> r
                .path("/api/v1/**")
                .uri("http://legacy:8080")) // Старый monolith
            .build();
    }
}

Вариант 2: Radical rewrite (более рискованный)

Выбор: Strangler pattern — снижает риск, позволяет постепенно мигрировать

Результаты:

• Время деплоя упало с 15 минут до 2-3 минут
• Независимое развёртывание каждого сервиса
• Горизонтальное масштабирование отдельных компонентов
• Возможность использовать технологии по назначению (NodeJS для API, Python для аналитики и т.д.)

Кейс 2: Кэширование в распределённой системе

Проблема: В системе обработки заказов E-commerce данные кэша на разных инстансах были несогласованными. Кэш обновлялся на одном сервере, но другие сервера возвращали старые данные.

Варианты решения:

1. Local Caffeine Cache — простое, но неправильное

@Configuration
public class CacheConfig {
    @Bean
    public Cache<String, Product> localCache() {
        return Caffeine.newBuilder()
            .maximumSize(1000)
            .expireAfterWrite(5, TimeUnit.MINUTES)
            .build();
    }
}
// Проблема: кэш не синхронизируется между серверами

1. Redis как shared cache — надёжнее, но медленнее

@Configuration
@EnableCaching
public class RedisCacheConfig {
    @Bean
    public LettuceConnectionFactory connectionFactory() {
        return new LettuceConnectionFactory();
    }
    
    @Bean
    public RedisCacheManager cacheManager(LettuceConnectionFactory connectionFactory) {
        return RedisCacheManager.create(connectionFactory);
    }
}

@Service
public class ProductService {
    @Cacheable(value = "products", key = "#id")
    public Product getProduct(Long id) {
        return productRepository.findById(id).orElse(null);
    }
    
    @CacheEvict(value = "products", key = "#id")
    public void updateProduct(Long id, Product product) {
        productRepository.save(product);
    }
}

1. Двухуровневое кэширование (оптимальное)

@Service
public class ProductService {
    @Autowired
    private Cache<String, Product> localCache; // Caffeine
    @Autowired
    private StringRedisTemplate redisTemplate;
    
    public Product getProduct(Long id) {
        String key = "product:" + id;
        
        // Уровень 1: быстрый локальный кэш
        Product fromLocal = localCache.getIfPresent(key);
        if (fromLocal != null) return fromLocal;
        
        // Уровень 2: общий Redis
        Product fromRedis = getFromRedis(key);
        if (fromRedis != null) {
            localCache.put(key, fromRedis);
            return fromRedis;
        }
        
        // Уровень 3: БД
        Product fromDB = productRepository.findById(id).orElse(null);
        if (fromDB != null) {
            saveToRedis(key, fromDB);
            localCache.put(key, fromDB);
        }
        return fromDB;
    }
}

Выбор: Двухуровневое кэширование — баланс между скоростью и консистентностью

Кейс 3: Выбор транзакционной модели в высоконагруженной системе

Проблема: платёжный микросервис должен гарантировать консистентность денежных средств при одновременных транзакциях, но ACID блокирует весь сервис под нагрузкой.

Варианты:

1. Pessimistic Locking (ACID)

@Service
public class PaymentService {
    @Transactional
    public void transfer(Long fromAccountId, Long toAccountId, BigDecimal amount) {
        Account from = accountRepository.findByIdForUpdate(fromAccountId);
        Account to = accountRepository.findByIdForUpdate(toAccountId);
        
        from.setBalance(from.getBalance().subtract(amount));
        to.setBalance(to.getBalance().add(amount));
        // COMMIT
    }
}
// Проблема: очень медленно при 10K транзакций/сек

1. Optimistic Locking (версионирование)

@Entity
public class Account {
    @Version
    private Long version; // Автоматический control
    private BigDecimal balance;
}

@Service
public class PaymentService {
    @Transactional
    public void transfer(Long fromId, Long toId, BigDecimal amount) {
        // OptimisticLockingFailureException при конфликте
    }
}
// Лучше, но всё равно много конфликтов при высокой конкурренции

1. Saga Pattern (BASE модель)

@Service
public class PaymentSaga {
    @Autowired
    private AccountService accountService;
    @Autowired
    private EventPublisher eventPublisher;
    
    public void transferMoney(TransferRequest request) {
        // Шаг 1: Резервируем деньги (idempotent)
        accountService.reserve(request.getFromAccountId(), request.getAmount());
        eventPublisher.publish(new MoneyReserved(request));
        
        try {
            // Шаг 2: Переводим
            accountService.transfer(request);
            eventPublisher.publish(new MoneyTransferred(request));
        } catch (Exception e) {
            // Компенсация (откат)
            accountService.releaseReserve(request.getFromAccountId(), request.getAmount());
            eventPublisher.publish(new MoneyReleasedCompensation(request));
        }
    }
}

Выбор: Saga Pattern — eventual consistency лучше для масштабирования, чем strict ACID

Ключевые принципы при принятии сложных решений

1. Data-driven approach: Меряем текущие проблемы, не предполагаем

• Профилирование перед оптимизацией
• Мониторинг и метрики

2. Risk assessment: Оцениваем риск каждого варианта

• Сложность реализации
• Возможность отката
• Влияние на production

3. Team capacity: Берём в расчёт знания и опыт команды

• Микросервисы требуют опыта распределённых систем
• Не вводим технологии "для галочки"

4. Постепенная миграция:

• Strangler pattern для рефакторинга
• Feature flags для безопасного развёртывания
• A/B тестирование новых подходов

5. Documentation:

• ADR (Architecture Decision Record) — фиксируем решение и причины
• Team review — обсуждаем с коллегами перед implementation