RTK Query: The Future of Data Fetching, Caching, and Redux

Introduction

Modern web applications require sophisticated data fetching strategies. Users expect instant responses, real-time updates, and seamless experiences even when network conditions are less than ideal. Managing server state--data that lives on your backend but is displayed in your React components--has historically been one of the most challenging aspects of frontend development. Redux Toolkit Query, commonly known as RTK Query, offers a powerful solution to these challenges by providing a purpose-built data fetching and caching library that integrates directly into the Redux ecosystem.

RTK Query represents a paradigm shift in how developers handle asynchronous data in React applications. Rather than manually managing loading states, implementing cache invalidation strategies, and writing boilerplate code for API calls, RTK Query abstracts these concerns into a declarative API that feels natural within the React component lifecycle. The library is built on top of Redux Toolkit's core APIs, meaning it inherits all the benefits of Redux's predictable state management while adding specialized functionality for server state. By recognizing that server state requires different treatment than client state, RTK Query provides a purpose-built solution that reduces boilerplate, eliminates entire categories of bugs, and enables sophisticated data management patterns.

Our team specializes in modern web development practices that leverage powerful tools like RTK Query to build performant, scalable applications. Throughout this guide, you'll learn how to define API slices, implement queries and mutations, manage cache effectively, and apply advanced patterns like optimistic updates and streaming cache updates. Whether you're building a new React application or looking to modernize an existing codebase, understanding RTK Query will transform how you approach data fetching in your projects.

Understanding API Slices

At the heart of RTK Query lies the concept of an API slice. An API slice is a logical grouping of related endpoints that share a common base configuration. When you create an API slice using the createApi function, you define how your application communicates with one or more backend services, including the base URL, expected endpoints, and various configuration options.

The createApi function accepts a configuration object with several key properties. The reducerPath specifies where the API slice's data will be stored in the Redux store, creating a dedicated namespace for all cached data and query state. The baseQuery handles the actual HTTP requests--typically using the built-in fetchBaseQuery utility, which provides a lightweight wrapper around the native fetch API with additional features like automatic base URL handling and response processing. The tagTypes array defines the cache invalidation tags that your API will use, enabling sophisticated cache management strategies.

The endpoints property is where you define your actual API operations using the builder pattern. Query endpoints use builder.query() to define read operations, while mutation endpoints use builder.mutation() for write operations. Each endpoint specifies its query function (which constructs the request URL), tags for cache management, and any transformations to apply to the response data. The resulting API slice automatically generates React hooks named according to a convention: use followed by the endpoint name, making it immediately clear what each hook does.

For example, a getPosts query endpoint generates useGetPostsQuery, while an addPost mutation generates useAddPostMutation. This consistent naming convention and the auto-generated hooks significantly reduce boilerplate compared to manual fetch implementations, allowing you to focus on building features rather than managing data fetching infrastructure.

Queries: Fetching Data with Confidence

Queries in RTK Query are operations that retrieve data from a server and store it in the client's cache. A query operation is initiated when a component mounts or when the query's arguments change, and RTK Query automatically handles the entire lifecycle of the request--from showing appropriate loading states to caching the results for future use. This automatic lifecycle management eliminates the need for manual effect handling and reduces the likelihood of common bugs like memory leaks from forgotten cleanup or race conditions from concurrent requests.

The builder.query method defines query endpoints with a flexible configuration. The query function receives any arguments passed to the hook and returns either a string URL or a configuration object for requests requiring headers, authentication, or non-GET methods. RTK Query queries intelligently determine when to make network requests versus serving cached data. When cached data is available and considered fresh, the query returns immediately without a network request. When data is stale or doesn't exist, RTK Query automatically triggers a network request, updates the cache, and provides fresh data to the component.

RTK Query supports multiple strategies for controlling when queries are fetched. The refetchOnFocus option causes queries to automatically refetch when the browser window regains focus, ensuring users see fresh data when returning to your application. Similarly, refetchOnReconnect automatically refetches when the application reconnects after being offline. These automatic behaviors can be configured globally on the API slice or overridden on individual endpoints, giving you fine-grained control over data freshness versus network efficiency.

The query hooks return comprehensive state information including isLoading (true only for the initial fetch), isFetching (true for any refetch), isSuccess, isError, error, data, and a refetch function. This rich state allows you to render appropriate UI for each scenario--showing skeleton loaders during initial loads, subtle refresh indicators during background refetches, error states with retry controls, and success states with the fetched data.

Mutations: Updating Server Data

Mutations represent operations that modify data on the server. Unlike queries, which are read-only operations, mutations can create, update, or delete resources. RTK Query's mutation system handles these operations gracefully, including automatic cache invalidation and optimistic updates for better user experience. The design philosophy emphasizes making mutations feel natural within the React component model while handling all the complex synchronization between client state and server state.

The builder.mutation method defines mutation endpoints with configuration similar to queries. Each mutation specifies how to construct the request through its query function, which returns either a string URL for simple operations or a configuration object for requests with bodies, custom methods, or additional headers. Critically, mutations can specify which cache tags should be invalidated when the mutation completes, triggering automatic refetches of affected queries to keep your UI synchronized with the server.

When a mutation is executed, RTK Query provides the current loading state, error information, and the returned data. Components can use this information to show loading indicators, display success messages, or update their local state to reflect the mutation's result. The mutation hooks return a trigger function that you call when you want to execute the mutation, along with state properties including isLoading, isError, isSuccess, and error. The trigger function returns a promise that resolves with the mutation result or rejects with an error, allowing standard try-catch error handling patterns through the unwrap() utility.

The seamless integration between mutations and the caching system is one of RTK Query's most powerful features. By defining appropriate invalidation rules, you ensure queries automatically refetch after mutations complete, eliminating manual cache updates and reducing the likelihood of stale data being displayed. This automatic invalidation is particularly valuable in complex applications where multiple components might display the same data--any component that triggers a relevant mutation will cause all queries providing that cache tag to refetch, keeping your entire application consistent.

Cache Management and Performance

RTK Query's caching system is built on the concept of subscription-based cache entries. When a query hook mounts in a component, it creates a subscription to that specific query's cache entry. The cache entry is identified by a unique cache key that combines the endpoint name and the query arguments. If multiple components subscribe to the same cache entry, they all receive the same cached data and share the reference count for that entry, eliminating redundant network requests and ensuring consistency across your application.

Cache Keys and Subscription Lifetimes

Understanding cache keys is essential for effective use of RTK Query. A cache key is a unique identifier for a specific query's cached data, constructed from the endpoint definition and the arguments passed to the query hook. Components that call the same query hook with the same arguments will share a cache entry, while components with different arguments will have separate cache entries. This key construction ensures that querying for all posts versus querying for a specific post results in different cache entries, preventing data from different queries from conflicting.

The subscription lifetime system ensures cache entries are cleaned up when they're no longer needed. Each time a component mounts and calls a query hook, it increments the subscription count for that cache entry. When the component unmounts, the subscription count is decremented. When the count reaches zero, RTK Query starts an internal timer representing the cache lifetime. By default, unused data is removed from the cache after 60 seconds, though this can be configured globally with keepUnusedDataFor or overridden on individual endpoints. If a new subscription is created before the timer expires, the timer is cancelled and the data is retained, allowing reuse of recently-fetched data.

Cache Invalidation Strategies

Cache invalidation is one of the most challenging aspects of any caching system, and RTK Query provides a powerful mechanism for managing it through tags. Tags are string identifiers that mark cached data as related to specific types of resources. When a mutation invalidates a tag, RTK Query automatically refetches all queries that provide that tag, ensuring the cache stays synchronized with the server state without manual intervention.

The tag system supports both general and specific tags for granular control. A general tag like 'Post' marks all posts data, while a specific tag like { type: 'Post', id: '123' } marks only the post with ID 123. When defining endpoints, you specify which tags they provide through providesTags and which tags invalidate them through invalidatesTags. These can be static strings, specific tag objects, or functions that compute tags based on response data or operation arguments.

An effective invalidation strategy typically involves providing specific tags for individual items and general tags for collections. When an item is updated, invalidating its specific tag ensures only that item is refetched, not the entire list. When a new item is created, invalidating the collection tag ensures the full list is refetched to include the new item. This granularity minimizes unnecessary network requests while ensuring data consistency, giving you the best of both worlds: the performance benefits of caching and the freshness of real-time data.

Advanced Patterns and Techniques

Optimistic Updates

Optimistic updates represent a powerful technique where the UI is updated immediately when a mutation is triggered, before the server confirms the operation was successful. This approach makes applications feel more responsive, as users see their changes reflected instantly rather than waiting for a round trip to the server. If the mutation fails, the UI is rolled back to its previous state and an error is displayed, making the application feel robust and reliable even under adverse network conditions.

RTK Query supports optimistic updates through the onQueryStarted lifecycle hook, which provides access to the query cache and the ability to update it programmatically. Within this hook, you can update the cached data to reflect the expected result of the mutation, making the UI feel instantaneous. If the mutation subsequently fails, you can use the queryFulfilled promise to catch the error and revert the cached data to its previous state. Implementing optimistic updates requires careful consideration of error handling and rollback scenarios--the optimistic update should reflect the most likely successful outcome, and the rollback mechanism should restore the exact previous state of the cache.

The benefits of optimistic updates are most noticeable in interactive applications where users frequently modify data. Comments, likes, form submissions, and other user interactions can all benefit from the immediate feedback that optimistic updates provide. However, the complexity of implementing and maintaining optimistic updates means they should be applied judiciously--typically for operations where the success rate is high and the user experience benefit is significant. For operations with lower confidence or higher risk, the traditional approach of waiting for server confirmation may be more appropriate.

Streaming Updates

RTK Query also supports streaming cache updates, a pattern where initial data is fetched through a traditional request-response cycle, and subsequent updates are delivered through a persistent connection such as a WebSocket. This pattern is particularly valuable for applications that need to display real-time data, such as dashboards, chat applications, collaborative tools, or any interface where data changes frequently and users expect to see updates without manual refreshing.

Streaming updates are implemented using the streaming option on query endpoints, which causes RTK Query to maintain an open connection and deliver updates as they arrive. When an update is received, RTK Query automatically merges it into the cached data and triggers a re-render of subscribed components. This seamless integration means components can display real-time data without any additional logic to handle incoming updates--the same query hook pattern works whether you're fetching once or receiving continuous updates.

The streaming capability is built on top of the same caching infrastructure as traditional queries, meaning you get all the benefits of RTK Query's cache management while also receiving real-time updates. Components can subscribe to streaming queries just like any other query, and the library handles the complexity of maintaining the connection and merging updates. This approach is particularly powerful for applications that need both historical data (fetched once) and real-time updates (delivered continuously) without having to manage separate data sources or synchronization logic. Integrating AI automation with real-time data patterns can create powerful intelligent features in your applications.

Manual Cache Manipulation

While RTK Query's automatic cache management handles most use cases, there are situations where you need to manually manipulate the cache. The updateQueryData utility function provided by the API slice allows you to programmatically modify cached data without triggering a network request. This can be useful for applying client-side transformations, implementing undo functionality, or synchronizing related cache entries when automatic invalidation isn't sufficiently granular.

The updateQueryData function takes the endpoint name, the query arguments, and an update function that receives the current cached data and returns the modified version. The update function is applied directly to the cached data in the Redux store, and all subscribed components will receive the updated data. This direct manipulation is particularly useful for implementing features like inline editing, where changes should be immediately visible without waiting for a server response, or for implementing optimistic updates that need to be rolled back manually.

Manual cache manipulation should be used carefully, as it can lead to inconsistencies between the client state and server state. Any manual updates should be considered temporary until confirmed by the server, and appropriate error handling should be in place to detect and recover from situations where the manual update diverges from the server's actual state. When used appropriately, however, manual cache manipulation provides flexibility for complex scenarios that fall outside the bounds of automatic cache management.

React Hooks Deep Dive

useQuery Hook Patterns

The useQuery hook is the primary interface for fetching data in RTK Query, automatically managing the entire lifecycle of data fetching including initial fetching, background refetching, and cache subscription. When you call this hook, it immediately returns an object containing the current data, loading state, error information, and a refetch function, allowing you to render appropriate UI for each state without managing complex side effects yourself.

The hook accepts two arguments: the query arguments (passed to the query function to construct the URL) and an options object controlling behavior. Options include the ability to skip the query under certain conditions using skip, force a refetch with refetchOnMountOrArgChange, or control polling interval with pollingInterval. The returned object provides data (the fetched response), error (any error that occurred), isLoading (true only for the initial fetch), isFetching (true for any refetch including background ones), isSuccess, isError, and refetch (a function to manually trigger a refetch).

The distinction between isLoading and isFetching enables nuanced loading UI patterns. isLoading is true only for the first fetch when no cached data exists, perfect for showing initial skeleton loaders. isFetching is true for any network request, including background refetches, allowing you to show subtle refresh indicators during subsequent updates without disrupting the user experience. This separation gives you the information needed to build interfaces that feel responsive without being jarring--initial loads show full loading states while background updates show minimal indicators.

Lazy Queries and Conditional Fetching

In addition to the eager useQuery hook that automatically fetches when mounted, RTK Query provides useLazyQuery for situations where you need more control over when fetching occurs. Lazy queries don't automatically execute when mounted; instead, they return a trigger function that you call to initiate the fetch, along with the current data and state. This approach is essential for implementing features like search with debouncing, where you want to wait until the user stops typing before making a request.

Lazy queries return [trigger, { data, isFetching, isError }] where the trigger function accepts arguments and returns a promise resolving to the result. The trigger function can be called manually when a search button is clicked, when a debounce timer fires, or in response to any other event. This gives you precise control over when network requests are made, preventing excessive API calls during rapid user input while still providing responsive search functionality.

The skip option on useQuery provides another mechanism for conditional fetching. When skip is true, the query won't execute until it becomes false. This is useful for implementing features like modal dialogs that load data when opened, where you want to avoid fetching data until the modal is actually displayed. Combined with the selectFromResult option for transforming data before it reaches components, these hooks provide powerful primitives for building sophisticated data fetching patterns.

Performance Optimization

Prefetching

Prefetching is a technique where data is loaded before it's actually needed, so it's available immediately when a component renders. RTK Query provides the usePrefetch hook and the prefetch method on query hooks for implementing prefetching strategies that make applications feel instantaneous. When data is prefetched, it's stored in the cache and subsequent queries for that data will return immediately without making a network request, eliminating perceived latency for common navigation patterns.

Prefetching is particularly effective for common navigation patterns. If users frequently navigate from a list view to a detail view, prefetching the detail data when the list renders can make the navigation feel instantaneous. The prefetch can be triggered on hover over a link, on component mount, or at any other point in the user flow where you anticipate the data will be needed. The usePrefetch hook accepts the endpoint name and optional arguments, triggering a fetch that caches the result for future use.

Effective prefetching requires understanding your application's usage patterns and balancing the benefits of instant loading against the cost of potentially fetching data that isn't needed. Not all data should be prefetched--reserve this technique for commonly accessed data where the performance benefit justifies the additional network traffic. Analytics on cache hit rates can help identify which data would benefit most from prefetching, ensuring your optimization efforts target the areas that matter most to users.

Selectors and Data Transformation

RTK Query automatically caches the raw data returned by queries, but many applications need to transform this data before displaying it. The selectFromResult option on query hooks allows you to specify a selector function that transforms the cached data before it's returned to the component. This transformation happens at the subscription level, meaning it doesn't affect the cached data itself--multiple components can apply different transformations to the same cached data without conflicts.

Selectors are particularly useful for computing derived data, filtering lists, or extracting specific fields from complex response structures. By using memoized selectors with libraries like Reselect, you can ensure that derived data is only recomputed when the underlying data changes, maintaining good performance even for expensive transformations. This is essential for applications that need to filter, sort, or transform large datasets without triggering unnecessary re-renders or expensive recalculations.

The selectFromResult option receives the full query result state and returns the data to pass to the component. This means you have access to not just the data, but also the loading state, error state, and other metadata. Components can use this to implement sophisticated patterns like showing filtered views while still responding to loading and error states appropriately. When combined with React's memo or similar techniques, selectors enable highly optimized components that only re-render when their specific data changes.

Code Splitting

RTK Query supports code splitting through conditional endpoint definitions, allowing large applications to load only the data fetching code they need. This is particularly valuable for applications with many API endpoints, where loading all endpoint definitions upfront can significantly impact initial bundle size and time-to-interactive. The generated hooks and utilities for endpoints are tree-shakeable, meaning unused endpoints won't be included in the final bundle when using modern build tools.

Code splitting can be implemented by conditionally defining endpoints based on the environment or by using dynamic imports when defining the API slice. For example, admin-only endpoints can be excluded from the main bundle and loaded only when an admin user logs in. This approach keeps the initial application load fast while still providing full functionality when needed. The API slice structure naturally supports this pattern since each endpoint is independently defined and only the endpoints you import will be included in your bundle.

When implementing code splitting with RTK Query, consider both bundle size and runtime performance. Conditional endpoint loading adds complexity to your data layer but can significantly reduce initial bundle size for large applications. The trade-off is that dynamically loaded endpoints may have a slight delay the first time they're accessed. For most applications, the benefits of reduced initial bundle size outweigh this consideration, making code splitting an essential optimization for applications at scale.

Comparison with Alternatives

RTK Query vs React Query

React Query (now TanStack Query) and RTK Query are both excellent data fetching libraries with similar core concepts but different integration approaches. React Query is framework-agnostic and focuses purely on server state management, while RTK Query is built specifically for Redux applications and integrates directly with the Redux store. Both libraries have proven themselves in production applications and offer similar features--caching, background refetching, optimistic updates, and automatic cache invalidation--but they take different architectural paths to achieve these capabilities.

The choice between them often depends on your existing technology stack and preferences. If you're already using Redux for client state, RTK Query provides a unified architecture where all state--client and server--lives in the same store with consistent patterns for data flow and debugging. The Redux DevTools integration makes it easy to inspect cache state and debug data flow across your entire application. If you're not using Redux or prefer a more focused solution that doesn't require Redux, React Query offers similar functionality without the additional dependency and learning curve.

The APIs differ in their approach but share the same fundamental concepts. Migration between them is possible but requires significant changes to the data fetching layer. Consider your team's familiarity with Redux, your existing architecture, and your long-term maintenance needs when choosing between these libraries. Both are excellent choices--the right one depends on your specific context and requirements.

RTK Query vs Apollo Client

Apollo Client is a comprehensive GraphQL client that includes data fetching, caching, and state management specifically designed for GraphQL APIs. While RTK Query can make requests to GraphQL endpoints, it doesn't provide GraphQL-specific features like automatic query parsing, normalized caching, or schema-aware operations. Apollo excels in GraphQL environments where its specialized features--like automatic update of all affected queries after a mutation--provide significant value.

For applications using REST APIs, RTK Query provides a more lightweight solution with less configuration overhead. The learning curve is gentler, and the API is simpler to understand for developers new to data fetching libraries. For GraphQL applications with complex queries and mutations, Apollo's specialized features may provide additional value that justifies its complexity. Some applications even use both libraries--Apollo for GraphQL operations and RTK Query for REST endpoints--though this approach adds architectural complexity and requires maintaining two data fetching systems.

The decision between Apollo and RTK Query often comes down to your API architecture. REST APIs work naturally with RTK Query's endpoint-based approach. GraphQL APIs with complex relationships benefit from Apollo's normalized cache. If you're building a new application, consider your API technology first--it will significantly influence which library is the better fit for your needs.

When to Choose RTK Query

RTK Query is an excellent choice for applications that already use Redux or are planning to adopt Redux for client state management. The library's deep integration with Redux means you get a unified architecture where all state lives in the same store, with consistent patterns for data flow and debugging. This is particularly valuable in large applications where the boilerplate reduction and automatic cache management provide significant benefits in maintainability and reduced bug potential.

The library is well-suited for medium to large applications where complex data fetching needs benefit from sophisticated caching and invalidation strategies. Teams valuing consistency and standardization will appreciate the opinionated patterns that reduce decision-making for individual developers. The automatic cache management reduces the likelihood of bugs related to manual state management, and the declarative API makes it easier to reason about when and how data is fetched.

For small applications with simple data fetching needs, the additional abstraction of RTK Query might not be necessary, and simpler approaches like React's built-in hooks with fetch might be more appropriate. Consider the complexity of your data layer, your team's familiarity with Redux, and your long-term maintenance needs when evaluating whether RTK Query is the right choice for your project.

Best Practices for Production

Error Handling

Robust error handling is essential for production applications, and RTK Query provides multiple mechanisms for managing errors gracefully. Query hooks return error information through the error property, and components can use this information to display appropriate error states, retry controls, or fallback content. The error object includes detailed information about what went wrong, making it easy to provide meaningful feedback to users.

Global error handling can be implemented through the onError option on the API slice configuration. This callback receives all errors from all endpoints, allowing you to implement centralized error logging, toast notifications, or authentication handling for session expiration. Global error handlers can also implement retry logic for transient errors, automatically refetching failed requests after a configurable delay. This centralized approach keeps error handling logic out of individual components while ensuring consistent behavior across your application.

For mutations, the unwrap utility function allows traditional promise-based error handling. When called on the mutation promise, unwrap will either return the response data or throw an error, enabling standard try-catch patterns that might be more familiar to developers. This flexibility means you can choose between the callback-based approach of mutation state properties or the promise-based approach with unwrap, selecting the pattern that best fits your component's architecture.

Testing

Testing components that use RTK Query requires understanding how to mock the API layer and verify that components respond correctly to different query states. The library's hooks are designed to be testable, and the Redux store integration allows for comprehensive testing of data flow. Unit tests for components can use the query hooks with mocked data and verify that components render correctly for loading, success, and error states.

Integration tests can verify that cache invalidation works correctly and that components respond appropriately to data changes. The Redux DevTools can be used in tests to verify that the correct actions are dispatched and the cache is updated appropriately. This visibility into the data flow makes it easier to diagnose test failures and verify that your data fetching logic is working as expected.

Testing strategies should cover the full range of query states: initial loading, successful data retrieval, error states, refetching, and cache invalidation. Mock service workers can intercept actual network requests, allowing you to test against realistic API responses without relying on external services. This approach provides confidence that your application handles real-world scenarios correctly while maintaining test reliability and speed.

Scaling Considerations

As applications grow, data fetching complexity often increases. RTK Query supports this growth through several mechanisms: multiple API slices for different services, code splitting for endpoint definitions, and careful cache configuration for optimal performance. Multiple API slices can be created for different backend services or domains within your application, each maintaining its own cache while being combined into a single store configuration.

Cache configuration becomes increasingly important as applications scale. Shorter cache lifetimes reduce memory usage but increase network traffic, while longer lifetimes have the opposite effect. Understanding your application's usage patterns helps you tune these values appropriately. Analytics on cache hit rates and refetch frequency can inform these decisions, allowing you to optimize for the specific patterns of your users.

Code splitting endpoints by domain or user role can significantly reduce initial bundle size for large applications. Admin-only endpoints, for example, don't need to be loaded for regular users. This separation of concerns extends to team collaboration as well--different teams can work on different API slices independently while maintaining a consistent architecture across the application.

Conclusion

RTK Query represents a significant advancement in how React applications handle data fetching and caching. By recognizing that server state requires different treatment than client state, RTK Query provides a purpose-built solution that reduces boilerplate, eliminates entire categories of bugs, and enables sophisticated data management patterns. The library's declarative approach allows components to declare what data they need while RTK Query handles the complexities of fetching, caching, and synchronizing with the server.

Throughout this guide, we've explored the core concepts of API slices, queries, and mutations, along with advanced patterns like optimistic updates, streaming cache updates, and manual cache manipulation. These capabilities combine to create a comprehensive solution for server state management that integrates naturally with the React component model. The tag-based cache invalidation system provides granular control over when data is refetched, while the subscription-based caching ensures efficient use of network resources.

For applications already using Redux, RTK Query offers a seamless path to better data management without adding new dependencies or architectural complexity. For teams evaluating data fetching solutions, RTK Query's opinionated patterns and excellent TypeScript support make it an excellent choice for projects of any size. The patterns covered in this guide--proper cache invalidation, optimistic updates, prefetching, and error handling--lead to more maintainable and performant applications that provide excellent user experiences.

If you're looking to modernize your React application's data layer or build a new project with robust data management from the start, RTK Query provides the tools and patterns you need to succeed. Our team specializes in building scalable React applications with efficient data management strategies. Contact us to learn how we can help optimize your application's data fetching and state management. Our web development services include comprehensive React architecture consulting and implementation to help you build high-performance applications.

Sources

1. Redux Toolkit RTK Query Overview - Official documentation for RTK Query, Redux's data fetching and caching solution
2. RTK Query Queries Documentation - Detailed guide on queries, hooks, and data fetching patterns
3. RTK Query Cache Behavior - Comprehensive documentation on caching strategies and cache lifetime management
4. Redux.js.org Tutorial: RTK Query Advanced Patterns - Advanced patterns including cache invalidation, optimistic updates, and streaming updates