Reservvo

First version used Spring’s ApplicationEventPublisher to fire email after saving the booking. Events live in memory — if the process crashes between save() and send, the notification is lost. No retry, no visibility.

Migrated to Redis Streams with a consumer group. Producer publishes to the stream after persisting; @Async consumer sends via SES and XACKs. On failure, republishes with attempt + 1 until MAX_RETRY_ATTEMPTS = 2. Past that, goes to the Dead Letter Queue (reservvo:notifications:dlq) with timestamp and failure reason.

Paginating reservations loads Reservation → Resource → Provider → User. Without JOIN FETCH, Hibernate generates N+1 — 1 query for Reservation and N for each association.

JOIN FETCH on every association + DISTINCTto dedupe the cartesian. This breaks Spring Data’s automatic count on paginated queries (count with fetch join fails). Fix: separate countQuery in @Query, ignoring joins and counting only by filters. Result: 2 total queries (data + count) with zero N+1.

GET /api/reservations/slots is the most-called endpoint — clients see available times before booking. The computation fetches AvailabilityRule, iterates slots and calls existsConflict for each. Cached with @Cacheable on Redis, 10-minute TTL.

On creation, @CacheEvictworks directly (key comes from the request). On cancellations, the entity is already loaded from the DB and the annotation can’t resolve the key — manual eviction via CacheManager.getCache("slots").evict(key). In tests, cache is disabled via spring.cache.type=none and @Profile("!test") on RedisConfig.

A reservation must become COMPLETED once its time slot ends — but no request happens at that exact moment. Relying on the front to trigger the transition is fragile (the user may never come back), and computing it at read time leaves the actual state inconsistent in the database.

A scheduled job with @Scheduled(cron = "0 0 */4 * * *") runs every 4h and performs a bulk UPDATE (markExpiredAsCompleted) inside @Transactional, completing all overdue reservations at once — no N+1 and no external cron, using Spring's own @EnableScheduling, logging the affected count.

Zustand handles client state that persists across pages (JWT token, role, theme, sidebar). TanStack Query handles everything from the API — cache, automatic refetch, in-flight dedup, placeholderData: keepPreviousData for smooth pagination.

Components consume hooks (useProviderReservations, useReservationStats), and the matching mutation invalidates related queries.

The first version had queryClient.invalidateQueries(["slots"]) on every booking mutation — any create or cancel knocked out every cached slot, of every resource, on every date.

The fix was passing context through the mutation. On cancel, the mutation receives { id, resourceId, date } and invalidates exactly ["slots", resourceId, date] plus the ["reservations"] prefix. Slots of other resources stay intact. Query keys hierarchical from the start: ["reservations", "provider", page, size, status], ["slots", resourceId, date].