Preloaded Content Graphs for Redis Cache Retrieval
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional data retrieval techniques struggle to handle spikes in content selection requests, such as those occurring when popular content is made available, leading to overwhelming demands on the system.
Innovation Solution
Generating and storing entire content selection graphs in an in-memory data store like Redis cache, preformatted and pre-shaped for client-specific details, allowing for rapid retrieval and return of data without the need for on-demand formatting.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If conventional data retrieval techniques are used to fetch content selection data on-demand, then the system can handle general requests, but the system becomes overwhelmed during peak demand periods when simultaneous requests spike
Solution Approach 1:
The system pre-generates and stores content selection graphs in an in-memory data store before actual requests occur. These pre-built graphs are formatted and shaped in advance for different client types, allowing the system to respond instantly when requests arrive during peak demand periods, thereby maintaining both high productivity and system reliability.
2Adaptability or versatility
If content selection data is retrieved and formatted on-demand for each request, then the system can adapt to client-specific details, but the formatting process adds latency and reduces response time
Solution Approach 1:
The system pre-formats and pre-shapes content selection graphs for various client types in advance and stores them in the in-memory data store. When a request arrives, the system simply retrieves the pre-formatted graph corresponding to the client type, eliminating the need for real-time formatting operations and thus reducing latency while maintaining adaptability to different client specifications.
Solution Approach 2:
The system creates copies of content selection graphs pre-formatted for different client types and stores them in the in-memory data store. Instead of formatting data anew for each request, the system retrieves appropriate pre-formatted copies, which significantly reduces processing time and latency while still providing client-specific adapted responses.
3Loss of time
If the system stores pre-built content selection graphs in an in-memory data store, then response times improve during peak demand, but memory resources are consumed
Solution Approach 1:
The system pre-generates and stores only the necessary content selection graphs in the in-memory data store that are likely to be requested during peak demand periods. By anticipating and pre-building these graphs, the system optimizes response time for high-probability requests while managing memory usage efficiently.
Data Source
AI summary
The described technology is generally directed towards causing the generation of a content selection graph (or set of graphs) upon receipt of a notification that a new graph or replacement graph is needed with respect to a starting timepoint. For a new graph, a timepoint for that new graph indicates the need for the new graph at a given starting time. For a replacement graph, a notification (subscribed from a monitoring service) can indicate that an existing graph has changed; a replacement graph is generated with a graph identifier of the replacement graph, which then replaces the graph identifier of the existing graph in the mappings of valid graphs to start times. A Redis cache can be used to maintain the various graph sets, including the active graph sets and graph sets that will become active at a future time.