diff --git a/dev/architecture/highload/Инвалидация кэша.md b/dev/architecture/highload/Инвалидация кэша.md
index 8a8df711..7dd5c660 100644
--- a/dev/architecture/highload/Инвалидация кэша.md	
+++ b/dev/architecture/highload/Инвалидация кэша.md	
@@ -19,7 +19,6 @@ linked:
 	- При малом TTL будет высокий [CacheMissRate](CacheMissRate.md)
 	- При большом TTL данные могут быть не консистентны
 - Инвалидация по событию
-	- Удаляем старые данные при изменении в базе или по событию от кафки.
 	- Опасно из-за риска мгновенной инвалидации и сопутствующей [[Перестройка кэша|перестройки кэша]]
 - Использование [[../../algorithm/Алгоритмы вытеснения|алгоритмов вытеснения]]
 
@@ -29,11 +28,12 @@ linked:
 Один из подходов это инвалидация по времени. Для кэшированных данных устанавливается TTL, и по прошествию времени кэш удаляется. Такое вариант подходит для редко изменяемых данных, устаревание которых не приводит к серьезным проблемам в бизнес-логике, например словари.
 
 При таком варианте важно подобрать оптимальное время жизни кэша, слишком маленькое время жизни будет давать плохую производительность, слишком большое ухудшит опыт пользователей. В оценке эффективности кэша поможет метрика [[CacheMissRate]].
+## Инвалидация по событию
+В этом случае мы удаляем данные кэша по какому-то событию. Например, при вызове метода обновления данных можно удалить кэш, который связан с этими данными. В некоторых случаях можно не удалять, а сразу класть новые данные в кэш, если понимаете, что они скоро потребуются.
 
-Если просто установить TTL, то спустя какое-то время он истечет и данные будут удалены, но что если к ним постоянно обращаются. В некоторых случаях я использую подход, при котором при запросе данных из кэша проверяется оставшийся TTL, и если он меньше, чем некоторое значение, то TTL устанавливается заново.
-
-Данные остаются в кэше, если ими активно пользуются. В таком случае при обновлении данных, необходимо вручную положить новые данные или инвалидировать кэш по событиям.
+Инвалидацию по событию можно комбинировать с TTL. В таком случае при запросе данных из кэша можно проверять оставшееся время жизни, и если оно меньше, чем некоторое заданное значение, то установить TTL заново. Таким образом данные остаются в кэше, если ими активно пользуются.
 
+Пример реализации механизма обновления TTL на Lua:
 ```lua
 local key = KEYS[1];
 local threshold = tonumber(ARGV[1]);
diff --git a/education/Метапознание.md b/education/Метапознание.md
index 5cbd0982..66d13554 100644
--- a/education/Метапознание.md
+++ b/education/Метапознание.md
@@ -3,7 +3,7 @@ aliases:
   - метапознание
 tags:
   - maturity/🌱
-date: "[[2023-10-28]]"
+date: 2023-10-28
 zero-link:
   - "[[../meta/zero/00 Образование|00 Образование]]"
 parents: 
diff --git a/health/disease/Синдром беспокойных ног.md b/health/disease/Синдром беспокойных ног.md
index b40ca788..f0438e6c 100644
--- a/health/disease/Синдром беспокойных ног.md	
+++ b/health/disease/Синдром беспокойных ног.md	
@@ -3,7 +3,7 @@ aliases:
   - СБН
 tags:
   - maturity/🌱
-date: "[[2023-10-26]]"
+date: 2023-10-26
 zero-link:
   - "[[../../meta/zero/00 Здоровье|00 Здоровье]]"
 parents: