<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>ETag on</title><link>https://eunus.dev/tags/etag/</link><description>Recent content in ETag on</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Sun, 28 Jun 2026 00:00:00 +0600</lastBuildDate><atom:link href="https://eunus.dev/tags/etag/index.xml" rel="self" type="application/rss+xml"/><item><title>Version-Based Cache Validation in ABP — Keeping the Application Layer Clean Without Redis</title><link>https://eunus.dev/blog/version-based-cache-validation-in-abp-keeping-the-application-layer-clean-without-redis/</link><pubDate>Sun, 28 Jun 2026 00:00:00 +0600</pubDate><guid>https://eunus.dev/blog/version-based-cache-validation-in-abp-keeping-the-application-layer-clean-without-redis/</guid><description>Every caching tutorial I found did the same thing: reach into the application service, wrap the method body in GetOrCreateAsync, and call it clean architecture. The service now knows it&amp;rsquo;s being cached. It has a cache key. It has an invalidation call in the delete method. It has become a caching service with a thin layer of business logic underneath.
That bothered me. The application layer is supposed to contain orchestration and business use cases — not decide whether a response came from memory or a database.</description></item></channel></rss>