# LLD: Proxy Design Pattern (Structural)

## Метаданные

- **Канал:** Concept && Coding - by Shrayansh
- **YouTube:** https://www.youtube.com/watch?v=GqLTodZ7t9U
- **Дата:** 06.05.2026
- **Длительность:** 1:48
- **Просмотры:** 10,439
- **Источник:** https://ekstraktznaniy.ru/video/50000

## Транскрипт

### Segment 1 (00:00 - 01:00) []

In my view, one of the most frequently used design pattern is proxy design pattern. One good example is in a spring boot when we use at the rate cacheable, we are indirectly using proxy design pattern where every call is first intercepted by proxy pattern. It first check whether the data is present into cache or not. If not, then only it will hit the DB, else not. Another good example is transactional where when you will try to invoke a method, instead of directly invoking the method, it first intercepted by proxy and it wrap this real code, real method with the transactional logic like a start transaction and commit or rollback logic. How does it work? So, let's say we have an interface user service which has one method get user. Now, we have one class called real user which implements this user service and also provide the implementation of get user method. So, where it actually invokes DB to fetch the details. So, in proxy design pattern, we create another child class, let's say proxy user. Now, this proxy user class has real user object. So, it has a dependency with the real user. This proxy user also maintain cache. So, in this case, I'm just maintaining this cache via hash map. During the implementation of get user method, it first check into its cache whether the data is present there or not. If present, it return the data from cache itself. It do not even call DB. But if data is missing into the cache, it invokes the real user method which ultimately calls the DB, get the data and this proxy user update its cache. And then, how it served to the user. This is just a usage example. Whenever we ask for user service object, we always get proxy user object and I'm making two times call. First time, it will go to the DB, that's why it's slow. Second time, it will serve from the cache itself.