Разрабатывал ли сервис с большим количеством пользователей

Сервисы с большим количеством пользователей

Да, я разрабатывал несколько сервисов, которые обслуживали сотни тысяч активных пользователей. Это был основной фокус моей карьеры в последние 5 лет. Расскажу о самом крупном проекте и выводах.

Проект: платёжная система с высокой нагрузкой

Масштаб:

• 500K+ активных пользователей в пик
• 100K+ транзакций в секунду
• 99.99% uptime SLA
• Обработка денежных потоков (финтех)

Архитектура:

Load Balancer (nginx)
    ↓
API Gateway (Spring Cloud Gateway)
    ↓
Microservices (Spring Boot):
  • Payment Service
  • User Service
  • Transaction Service
  • Notification Service
    ↓
Data Layer:
  • PostgreSQL (master-slave)
  • Redis (кеширование)
  • Kafka (асинхронные события)

Ключевые вызовы при высокой нагрузке

1. База данных — главное узкое место

Самая большая ошибка новичков — мысль, что БД просто масштабируется. На деле нужна целая стратегия:

// ПРОБЛЕМА: N+1 запросы при большой нагрузке
@RestController
public class UserController {
    @GetMapping("/users/{id}")
    public UserDto getUser(@PathVariable Long id) {
        User user = userRepository.findById(id);
        // Каждый вызов fetchType.LAZY запустит отдельный запрос!
        user.getOrders();
        user.getPayments();
        // При 100K пользователей = 300K запросов
    }
}

// РЕШЕНИЕ: Fetch JOIN или нативные запросы
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    @Query("SELECT DISTINCT u FROM User u LEFT JOIN FETCH u.orders LEFT JOIN FETCH u.payments WHERE u.id = :id")
    Optional<User> findByIdWithEagerLoad(@Param("id") Long id);
}

2. Кеширование — спасение от БД

Использовали Redis на полную мощь:

@Service
public class UserService {
    private final UserRepository repository;
    private final RedisTemplate<String, User> redisTemplate;
    
    private static final String CACHE_KEY = "user:";
    private static final long CACHE_TTL = 3600;
    
    public User getUserWithCache(Long userId) {
        String key = CACHE_KEY + userId;
        User cached = redisTemplate.opsForValue().get(key);
        if (cached != null) {
            return cached;
        }
        User user = repository.findById(userId)
            .orElseThrow(() -> new UserNotFoundException(userId));
        redisTemplate.opsForValue().set(key, user, Duration.ofSeconds(CACHE_TTL));
        return user;
    }
}

3. Асинхронная обработка — избегаем блокировок

Дорогие операции делали асинхронными через Kafka:

@Service
public class PaymentService {
    private final KafkaTemplate<String, PaymentEvent> kafkaTemplate;
    
    public PaymentResponse processPayment(PaymentRequest request) {
        validateBalance(request.getUserId(), request.getAmount());
        Payment payment = Payment.create(request);
        Payment saved = paymentRepository.save(payment);
        PaymentEvent event = new PaymentEvent(saved.getId(), saved.getUserId(), saved.getAmount());
        kafkaTemplate.send("payment-events", event);
        return PaymentResponse.from(saved);
    }
}

@Service
public class PaymentEventHandler {
    @KafkaListener(topics = "payment-events")
    public void handlePaymentEvent(PaymentEvent event) {
        notificationService.sendEmail(event.getUserId());
        analyticsService.logPayment(event);
        reportingService.updateStats(event);
    }
}

4. Индексирование базы данных

CREATE INDEX idx_user_email ON users(email) WHERE deleted_at IS NULL;
CREATE INDEX idx_payment_user_date ON payments(user_id, created_at DESC);
CREATE INDEX idx_transaction_status ON transactions(status, created_at);

5. Мониторинг и метрики

@RestController
@RequestMapping("/api/v1/payments")
public class PaymentController {
    private final MeterRegistry meterRegistry;
    
    @PostMapping
    public PaymentResponse createPayment(@RequestBody PaymentRequest request) {
        Timer.Sample sample = Timer.start(meterRegistry);
        try {
            PaymentResponse response = paymentService.processPayment(request);
            meterRegistry.counter("payment.created", "status", "success").increment();
            sample.stop(Timer.builder("payment.processing.time")
                .publishPercentiles(0.5, 0.95, 0.99)
                .register(meterRegistry));
            return response;
        } catch (InsufficientBalanceException e) {
            meterRegistry.counter("payment.failed", "reason", "insufficient_balance").increment();
            throw e;
        }
    }
}

Метрики, на которые мы смотрели

Критичные:

• P95, P99 латенсия (целевая < 100ms)
• Error rate (целевая < 0.1%)
• QPS при пиковой нагрузке
• CPU/Memory usage

Вторичные:

• Cache hit rate (целевой > 90%)
• Database connection pool usage
• Garbage collection pauses

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

1. Архитектура важнее кода — невозможно оптимизировать плохую архитектуру. Нужны микросервисы, асинхронность, кеширование.

2. Database первый враг — даже небольшое улучшение в БД может дать 10x улучшение в производительности.

3. Мониторинг с первого дня — нельзя оптимизировать, если не видишь, где проблемы.

4. Нагрузочное тестирование обязательно — не надо ждать, пока система упадёт в продакшене.

5. Graceful degradation — всегда планируем, что может сломаться и как система будет работать в деградированном режиме.

Этот опыт сделал меня инженером, который понимает не только код, но и то, как код работает на настоящих системах под нагрузкой.