Впровадила deep‑merge на основі каталогу для збережених JSON‑налаштувань, запобігши збоям через відсутні ключі при еволюції схеми.

Ситуація. Платформа зберігає JSON‑налаштування — налаштування сповіщень і подібне — як збережені значення користувача, накладені поверх набору значень за замовчуванням. Початкове злиття робило це на одному рівні. Проблема виявляється пізніше: додається новий ключ до значень за замовчуванням, а рядки, збережені до появи цього ключа, просто його не мають. Тоді якийсь клієнтський код читає це поле, отримує undefined і падає — саме для тих користувачів, які тут найдовше.

Завдання. Розвиток схеми налаштувань мав бути безпечним, щоб додавання нового параметра ніколи не ламало людей, які зареєструвалися до того, як він з’явився.

Дія. Однорівневе злиття замінено на deep‑merge, керований значеннями за замовчуванням як каталогом. Значення за замовчуванням розглядаються як авторитетний перелік усіх ключів, які мають існувати; збережені значення користувача рекурсивно накладаються зверху, тож усе, що є в каталозі, гарантовано присутнє на виході — незалежно від того, чи було воно в збереженому blob. Додається ключ до значень за замовчуванням — і він автоматично з’являється в ефективних налаштуваннях кожного наявного рядка, включно з вкладеними ключами. Це впроваджено через міграцію, тож наявні дані отримали перевагу одразу, а не чекали на переписування.

Результат. Налаштування можуть зростати без побоювань. Додавання параметра більше не ризикує крашем через undefined‑поле на клієнті, а фронтенд перестав потребувати захисних перевірок, розкиданих у кожному місці, де він читає налаштування. Це також дало решті платформи надійний спосіб розширювати будь‑який збережений JSON‑blob — не лише окреме виправлення, а й сам патерн.