Reservvo

Primeira versão usava ApplicationEventPublisher do Spring para disparar email após salvar reserva. Eventos vivem em memória — se o processo cai entre o save() e o envio, a notificação se perde. Sem retry e sem visibilidade.

Migração para Redis Streams com consumer group. Producer publica no stream após persistir; consumer @Async envia via SES e dá XACK. Em falha, republica com attempt + 1 até MAX_RETRY_ATTEMPTS = 2. Estourou, vai para Dead Letter Queue (reservvo:notifications:dlq) com timestamp e razão da falha.

Listar reservas paginadas carrega Reservation → Resource → Provider → User. Sem JOIN FETCH, Hibernate gera N+1 — 1 query para Reservation e N para cada associação.

JOIN FETCH em todas as associações + DISTINCT para desduplicar. Isso quebra o count automático do Spring Data em queries paginadas (count com fetch join falha). Solução: countQuery separado no @Query, ignorando os joins e contando só pelos filtros. Resultado: 2 queries totais (data + count) com zero N+1.

GET /api/reservations/slots é o endpoint mais chamado — cliente vê horários antes de reservar. A consulta busca AvailabilityRule, itera slots e chama existsConflict para cada um. Cache com @Cacheable no Redis, TTL 10 min.

Na criação, @CacheEvict resolve direto (key vem do request). Em cancelamentos, a entidade já está carregada do banco e a annotation não resolve a key — eviction manual via CacheManager.getCache("slots").evict(key). Em testes, cache é desabilitado via spring.cache.type=none e @Profile("!test") no RedisConfig.

Uma reserva precisa virar COMPLETED quando seu horário termina — mas nenhum request acontece nesse instante. Depender do front pra disparar a transição é frágil (o usuário pode nunca voltar), e calcular no momento da leitura deixa o estado real inconsistente no banco.

Job agendado com @Scheduled(cron = "0 0 */4 * * *") roda a cada 4h e faz um UPDATE em lote (markExpiredAsCompleted) dentro de @Transactional, finalizando todas as reservas vencidas de uma vez — sem N+1 e sem cron externo, usando o @EnableScheduling do próprio Spring, com log da quantidade afetada.

Zustand cuida de estado de cliente que precisa persistir entre páginas (token JWT, role, tema, sidebar). TanStack Query cuida de tudo que vem da API — cache, refetch automático, dedup de requests em flight, placeholderData: keepPreviousData para paginação suave.

Componentes consomem hooks (useProviderReservations, useReservationStats), e a mutation correspondente invalida as queries relacionadas.

Primeira versão tinha queryClient.invalidateQueries(["slots"]) em todas as mutations de reserva — qualquer criação ou cancelamento derrubava todos os slots cacheados, de qualquer recurso, em qualquer data.

A correção foi passar contexto pela mutation. Ao cancelar, a mutation recebe { id, resourceId, date } e invalida exatamente ["slots", resourceId, date] além do prefixo ["reservations"]. Slots de outros recursos ficam intactos. Query keys hierárquicas desde o início: ["reservations", "provider", page, size, status], ["slots", resourceId, date].