caching

Menulis baris settings langsung ke database tidak mengubah respons API yang menyimpan snapshot saat boot. Urutan debug tiga lapis dan aturan restart.

TL;DR: Update settings langsung lewat SQL memang masuk di database, tapi endpoint masih balikin nilai lama soalnya API cuma baca snapshot in-memory yang dibuat pas boot. Nulis SQL itu nggak lewat jalur yang bisa refresh snapshot, makanya datanya kelihatan aman tapi nggak pernah kepakai. Solusinya gampang: habis nulis langsung ke DB, tinggal restart API-nya.

Nambah filter ?module= bukan cuma urusan WHERE: validasi 400 di handler, subquery parameterized, dan cache key per kombinasi filter.

TL;DR: Cachenya awalnya cuma mappoints:all jadi kalau filter module cuma ditempel di SQL, data bisa ketuker parah. Makanya dibikin tiga lapis pertahanan biar aman. Validasi dulu kalau modulnya ngaco langsung 400, query-nya pakai parameterized, dan cache key-nya dipisah sesuai filter.

Ganti cara invalidasi cache jawaban chat AI: bump versi namespace dengan INCR supaya key lama unreachable, bukan dihapus satu-satu.

TL;DR: Jawaban chat AI yang di-cache di Redis jadi basi tiap artikel berubah, dan masalah utamanya bukan SCAN yang blocking melainkan fan-out invalidasi yang rumit. Solusinya versioned key: tiap mutasi nge-bump counter versi via INCR, key lama jadi unreachable dan mati sendiri lewat TTL 24 jam. Bonusnya ada lookup mundur ke versi sebelumnya dan fallback persona saat LLM down.

Opsi --chat-url bikin translate EN pakai chat Qwen lama, satu chat buat dua artikel, plus pelajaran caching fetch Next.js 15.

TL;DR: Pipeline translate blog penulis awalnya boros kuota karena Qwen membuka chat baru tiap generate. Solusinya opsi --chat-url yang melanjutkan sesi lama, jadi satu chat menghasilkan artikel dua bahasa sekaligus. Bonusnya, penulis belajar caching Next.js 15 yang tak lagi otomatis, sehingga pipeline makin hemat, stabil, dan mudah dirawat.