### 1. Problem Situation
While implementing the function to view a specific user list on the admin page, I was using a query logic with many conditions and complex sorting criteria.
In the query process, not only was data simply retrieved, but target condition calculations, state determinations, and sorting processes were also carried out, and the same operations were repeatedly performed every time a request came in.
At first, I thought it was just a simple query function, but I began to notice that the same data was being recalculated repeatedly with each request.
Although the data was not real-time and continuously changing due to its nature, I felt that reconstituting all the data for each request was inefficient from an operational efficiency perspective.
Such a structure had the following issues.
- Repeated calculation of the same data
- Increase in unnecessary DB queries
- Repeated execution of complex sorting and filtering logic
- Potential performance degradation as data size increases
Rather than simply approaching it with query optimization, it was necessary to rethink the flow of generating and using data.
### 2. Approach
The data showed a characteristic of not undergoing significant changes over the course of a day.
Based on this observation, we applied a structure that generates data on a **daily basis and reuses it thereafter**, instead of calculating the data with each request.
In other words, instead of a structure that calculates data at each point of view, we changed the direction to generate data only when needed and to reuse already generated data.
The most important aspect we considered in this process was 'When will we generate new data?'
I concluded that a structure that can clearly manage the creation point is needed rather than a method that temporarily stores in memory like simple caching.
### 3. Implementation Method
#### 3.1 Data Structure Separation
In order to apply a daily reusable structure, the data was divided into two categories for management.
| Division | Role |
|------|------|
| Reference Date Data | Determining Whether to Generate Data for the Same Day |
| Query Target Data | Data Used for Actual Queries Storage |
The reference date data serves to determine whether the data generation has already been performed based on the current date.
On the other hand, the data for retrieval stores data that is reused during the actual retrieval.
I tried to keep the data flow simple by separating the data that manages the creation status from the actual query data.
Additionally, in a production environment, situations such as application restarts or multiple request scenarios may occur, so I concluded that a database-based management approach is more appropriate than memory-based management.
#### 3.2 Data Generation and Reuse Flow
When a request comes in, first check whether the data for the current date already exists.
If there is no data for the specified date, all data will be generated upon the first request.
Subsequently, it is configured to use the already generated data for queries.
The processing flow is as follows.
1. Check for the existence of data based on the current date.
2. If there is no data, perform the generation of entire data
3. If data exists, perform a retrieval without the generation process
4. Return of query results
This structure ensures that data is generated only once initially, and thereafter follows a reuse flow.
#### 3.3 Data Generation Logic
The data generation is designed not to simply delete all existing data and create new data, but to restructure based on the latest data while retaining some of the existing state.
The following tasks are performed during the generation process.
- Remove existing data that is no longer valid.
- Restructuring target data according to the latest standards
- Retaining some existing status values
- Reference date data registration
In particular, I emphasized the importance of maintaining the existing state values.
Every time the data is completely reset, information modified by administrators during the operation process may be lost.
Therefore, we organized it to retain only the necessary values after confirming the existing data.
### 4. Design Intent and Effect
The comparison between the existing method and the improved structure is as follows.
| Division | Existing Method | Improved Method |
|------|----------|----------|
| Data Processing Method | Calculated per request | Reused after initial creation |
| DB Query | Repeated queries occur | Queries performed only after creation |
| Response Flow | Can vary for each request | Keep consistent |
| Computational Cost | Occurs with repeated calculations | Performed only during initial creation |
| Data Management Method | Focus on Query Time | Focus on Creation Time |
Through this structure, it was possible not only to simply reduce the number of queries but also to separate the data creation time from the query time.
This structure is designed to prioritize reuse efficiency over computational cost, considering the data characteristics where real-time performance is not critically important.
Additionally, by managing the data based on the creation timestamp, we were able to keep the query flow itself simple.
### 5. Retrospective
At first, I thought it was just a simple query function, but during the implementation process, I faced the question, 'Why are we repeatedly recalculating the same data?'
And following that question, I realized that more important than simple query optimization is the issue of 'when to create data and how to manage it.'
Through this work, I learned that performance improvement is not just about making retrieval speeds faster, but rather about redesigning the data flow itself.
It could be experienced that not only the query logic but also the timing of data creation, state retention methods, and reuse structure must be considered together to create a stable operational structure.
zero