Cache
Cache
What is a cache?
- Frequently used data, stored nearby in advance
- Retrieved faster next time
- A core speed technique
What a cache changes is not where data comes from, but who trusts a copy to be the real thing, and for how long. The moment you use a cache, your system holds two truths, the original and the copy, and operators must choose whether to put response speed or freshness of information first. So cache settings are not just a technical decision for developers. They come down to a business standard: how many minutes can stale information be shown? For screens like prices and inventory, where an error costs money, the business side should be involved in setting that standard.
A cache isn't in one place; it builds up in layers. The user's browser, the CDN in front of it, the in-memory store on the server (such as Redis), and database query results each hold their own copy. Retention is set in seconds with Cache-Control max-age or a TTL value: images and fonts that rarely change get anywhere from a few days to a year, while values that change often, like prices and stock, get 30 to 60 seconds. Clearing just one layer won't change what appears on screen, and this is the point that trips teams up most often in practice. Unlike a session that holds login state, or a cookie, a cache is designed on the premise that work must not stop if it gets cleared.
The usual breakdown in practice is one sentence: 'It looks fine on my screen.' When a staffer hard-refreshes to clear only their own browser copy and reports the deployment as done, tens of thousands of customers keep seeing a days-old notice or the wrong price from the stale copy left on the CDN. The opposite move is just as risky: turning caching off entirely out of anxiety. At peak traffic every request goes straight to the DB, responses slow down, and a speed problem becomes an outage. The safe approach is not to switch caching off, but to publish only the changed files under new addresses.
Seungtae ParkHands-on AX instructor who teaches AI business development and marketing automation by building real systems
John KimInstructor John Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”It started as a hardware technique: computers placed fast temporary storage in front of slow storage devices to ease bottlenecks. It has since grown into a performance principle used across the web and software.
Let's look at a hypothetical case. Company A is a household goods distributor with 240 employees and about KRW 80 billion (≈ US$59,853,400) in annual revenue, processing 120,000 orders a month on its own online store. On the first day of its March spring promotion, it deployed the discounted prices, and within two hours customer service received 180 inquiries saying 'the price on screen differs from the amount charged.'
- Kim, a manager on the e-commerce team, opened the product page on their own PC and said, 'The sale price of KRW 12,900 (≈ US$10) looks right.' But the screenshot a customer sent still showed the regular price of KRW 18,000 (≈ US$13).
- Lee, a team lead on the development team, checked the access logs and found that 87% of all requests were being handled by the CDN without ever reaching the server, and the product detail page TTL was set to 24 hours.
- Team Lead Lee force-purged the cache for just the product detail paths in the CDN console. Fifteen minutes later, related inquiries had dropped from 90 per hour to 6.
- To prevent a repeat, they lowered the TTL to 60 seconds for pages that include prices or stock, kept images and fonts at 30 days, and added a rule to attach a deployment version value to file names.
- At the next month's summer promotion release, there were 0 inquiries about incorrect prices. Because the cache hit rate stayed at 91%, first-screen load time was effectively unchanged, going from 1.8 to 1.9 seconds.