เวลาแก้บทความ เรามักเปิดหน้าจัดการ กดบันทึก แล้วเปิดหน้าสาธารณะดูอีกครั้ง ถ้าเห็นข้อความใหม่ก็รู้ว่าทางที่เราเปิดอยู่ได้รับฉบับที่ต้องการแล้ว แต่บางครั้งอีกเครื่องยังเห็นข้อความเดิม หรือหน้าแสดงชื่อใหม่แล้วเนื้อหากลางหน้ายังเป็นของเก่าอยู่
อาการนี้ชวนให้คิดถึง cache ได้ แต่ก่อนจะล้างทุกอย่าง ยังควรดูว่าข้อมูลเก่ามาจากจุดไหน เพราะหน้าหนึ่งอาจประกอบจากผลเรนเดอร์ HTML ข้อมูล API และรูปภาพที่ถูกเก็บแยกกัน การล้างเพียงจุดเดียวอาจยังเหลืออีกส่วน หรือไปทำให้บริการส่วนอื่นเสียประโยชน์จาก cache โดยไม่เกี่ยวกับปัญหา
วิธีตรวจที่ช่วยได้คือไล่ฉบับข้อมูลตามเส้นทางครับ เริ่มจากสิ่งที่บันทึกจริงไปจนถึง response ที่ผู้ใช้ได้รับ แล้วค่อยเลือกว่าจะรอ ตรวจยืนยัน หรือทำให้ข้อมูลจุดไหนหมดอายุ แทนการอธิบายกับคนอ่านว่าเป็น cache ทั้งที่ยังไม่เห็นหลักฐาน
การบันทึกสำเร็จยืนยันได้ว่าต้นทางที่ระบบเขียนลงมีฉบับใหม่ แต่ถ้าแอปสร้าง HTML ไว้ก่อน หรือมี cache ของผลค้นข้อมูลอีกชั้น การอ่านหน้าสาธารณะอาจยังไม่ไปใช้ข้อมูลชุดนั้นทันที
จึงควรแยกการตรวจต้นฉบับจากการตรวจผลที่แอปส่งออก หากเข้าถึงฐานข้อมูลได้ตามสิทธิ์ ก็ตรวจข้อความหรือรหัสฉบับที่คาดไว้ก่อน แล้วอ่าน response ของหน้าจริงเพื่อดูว่ามีเนื้อหานั้นหรือไม่ การเห็นเวลา updatedAt ใหม่อย่างเดียวไม่ยืนยันว่าทุก field ถูกบันทึกตามที่ต้องการด้วย
สำหรับหน้าเว็บที่เปิดโครงก่อนแล้วเรียก API ตามมา ต้องตรวจทั้ง HTML กับ API เพราะข้อความที่มองเห็นบนหน้าจออาจถูกแทนที่ภายหลังได้ หากดูเพียง View Source ก็อาจไม่เจอเนื้อหาที่ browser กำลังแสดง แต่ถ้าดูเพียงหน้าจอก็ยังไม่เห็นว่า request ไหนเป็นตัวส่งข้อมูลเก่ามา
รหัสฉบับที่ผูกกับผลตอบกลับช่วยตามเรื่องนี้ได้ เช่น เก็บ content revision ในข้อมูลหรือเครื่องมือวินิจฉัยของระบบ โดยต้องสัมพันธ์กับ body ที่ส่งจริง ไม่ใช่รหัสล่าสุดที่อ่านจากฐานต่างหาก เพราะถ้าสองส่วนมาคนละฉบับก็จะยิ่งทำให้ตรวจผิดทาง
Cache-Control ใช้กำหนดเงื่อนไขที่ cache นำ response ไปใช้ต่อได้ เช่น อายุความสดของข้อมูล หรือข้อกำหนดให้กลับไปตรวจยืนยันก่อนใช้ซ้ำ จึงควรอ่าน header ของ URL ที่มีปัญหา ไม่อนุมานจากค่าที่ตั้งไว้ในไฟล์โดยยังไม่ตรวจสิ่งที่ส่งออกจริง
ETag เป็นตัวตรวจสอบฉบับที่ server กำหนดให้ representation ส่วน Last-Modified บอกเวลาที่ server ระบุว่าแก้ไขครั้งล่าสุด เมื่อผู้เรียกส่งเงื่อนไขกลับมา server สามารถตอบ 304 หากเงื่อนไขรองรับการใช้ฉบับเดิมได้ ซึ่ง response แบบนี้ไม่ได้แนบ body ฉบับเต็มใหม่มาให้
ดังนั้นการเห็น 304 ไม่ใช่ข้อผิดพลาดในตัวเอง แต่ต้องตรวจว่าค่าที่ใช้ตัดสินสอดคล้องกับเนื้อหาหรือไม่ ถ้าเนื้อหาเปลี่ยนแล้ว validator ยังบอกเหมือนเดิม ผู้เรียกก็อาจใช้ body เก่าต่อด้วยเหตุผลที่ server ยืนยันมา
คำว่า no-cache ก็ไม่ได้แปลว่าห้ามเก็บ response โดยสิ้นเชิง ในรูปแบบทั่วไปเป็นการกำหนดให้ตรวจยืนยันก่อนนำไปใช้ซ้ำ ส่วน no-store เป็นข้อกำหนดเรื่องไม่เก็บ response การเลือกใช้ต้องตรงเป้าหมาย และไม่ได้หมายความว่าการเปลี่ยน header วันนี้จะตามไปลบสำเนาที่เก็บไว้ก่อนหน้าทุกแห่งให้ทันที
เว็บอาจมีทั้ง cache ของแอป CDN และ browser โดยแต่ละชั้นมี key และระยะอายุของตัวเอง หากเครื่องหนึ่งส่ง cookie อีกเครื่องไม่ส่ง หรือใช้ host กับ query ต่างกัน ก็อาจไปเจอคนละรายการ cache แม้คนดูจะรู้สึกว่าเปิดบทความเดียวกัน
จึงควรเก็บ URL เต็มที่ใช้ตรวจ รวมทั้งจังหวะที่เกิดและ request สำคัญที่ต่างกัน โดยระวังไม่คัดลอก cookie หรือ token ลงรายงานที่แชร์ต่อ การตรวจแบบไม่ล็อกอินอาจช่วยเปรียบเทียบทางสาธารณะได้ แต่ต้องบอกด้วยว่าต่างจากทางของผู้ดูแลอย่างไร
บางระบบยอมตอบฉบับเก่าระหว่างสร้างฉบับใหม่ตามนโยบาย stale ที่ตั้งไว้ จึงอาจมีช่วงที่บันทึกแล้วแต่ response ยังไม่เปลี่ยน หากเป็นพฤติกรรมที่ตั้งใจ ต้องระบุช่วงเวลาที่ยอมรับได้และตรวจว่าในที่สุดเปลี่ยนจริง ไม่ใช้คำอธิบายนี้ปิดเรื่องทั้งที่ cache ไม่เคยถูกอัปเดตเลย
ใน browser ยังอาจมีสถานะของแอปหรือ service worker ที่เกี่ยวข้องด้วย การปิด cache ในเครื่องมือพัฒนาจึงช่วยตรวจเฉพาะส่วนหนึ่ง และไม่เท่ากับควบคุมสำเนาที่ CDN หรือระบบเรนเดอร์ไว้ทั้งหมด ต้องดูว่าข้อมูลเก่าหายไปเมื่อเปลี่ยนเงื่อนไขใดจึงค่อยตามจุดนั้นต่อ
การแก้บทความหนึ่งเรื่องอาจกระทบทั้งหน้ารายละเอียด รายการบทความ หน้าแท็ก และ metadata สำหรับแสดงตัวอย่างลิงก์ หากระบบมีวิธี invalidate ตาม path หรือกลุ่มข้อมูล ควรผูกขอบเขตให้สอดคล้องกับสิ่งที่เปลี่ยน ไม่จบแค่หน้าที่กดแก้แล้วปล่อยชื่อกับรูปในหน้ารายการค้างไปอีกนาน
ขณะเดียวกัน การล้างทั้งหมดทุกครั้งอาจทำให้แอปต้องสร้างข้อมูลใหม่พร้อมกันมากกว่าที่จำเป็น จึงควรเริ่มจากความสัมพันธ์ของข้อมูล เช่น บทความใดใช้ปกนี้ และหน้าใดแสดงคำโปรยนี้ แล้วใช้กลไกของแพลตฟอร์มให้ตรงกับความสัมพันธ์นั้น
สำหรับรูป หากเปลี่ยนไฟล์แต่ใช้ URL เดิม ผู้เรียกที่เก็บรูปไว้ยังอาจไม่ขอใหม่ตามที่คาด การใช้ URL ที่เปลี่ยนตามฉบับไฟล์ช่วยให้แยกชิ้นงานได้ แต่ต้องอัปเดตจุดอ้างอิงที่เกี่ยวข้องด้วย และไม่ควรลบฉบับเก่าทันทีถ้ายังมีหน้าเว็บหรือ cache อ้างถึงอยู่
ส่วนข้อมูลส่วนบุคคลหรือข้อมูลที่ต้องตรวจสิทธิ์ มีเงื่อนไขต่างจากบทความสาธารณะ จึงต้องกำหนดนโยบายแยก ไม่ใช้ความต้องการให้บทความโหลดเร็วเป็นเหตุให้ shared cache ส่งข้อมูลของผู้ใช้รายหนึ่งไปให้อีกรายได้
ในการตรวจจริง เลือกข้อความที่เปลี่ยนอย่างชัดเจนหนึ่งจุดและรหัสฉบับที่สัมพันธ์กัน แล้วเปิดหน้ารายละเอียด หน้ารายการ และรูปที่เกี่ยวข้องผ่านทางสาธารณะ พร้อมบันทึก header และเวลา การตรวจเพียงว่า HTTP ได้ 200 ยังไม่พอ เพราะ 200 ก็อาจส่ง body เก่าหรือหน้าข้อผิดพลาดที่ระบบจัดสถานะผิดมาได้
ถ้าผลต่างกัน ให้เทียบจากต้นทางออกมาทีละชั้น และเปลี่ยนเงื่อนไขทีละอย่าง จะช่วยแยกว่าการล้างจุดไหนมีผล ไม่ควรเริ่มจากแก้หลายค่า รีสตาร์ต และล้างทุกชั้นพร้อมกันจนรู้เพียงว่าอาการหาย แต่ไม่รู้ว่าจะกลับมาเมื่อใด
เมื่อเลือกนโยบายได้แล้ว ควรตรวจทั้งการอัปเดตตามปกติและกรณีที่ขั้นสร้างฉบับใหม่ผิดพลาด เพื่อให้รู้ว่าผู้ใช้จะได้รับอะไรในช่วงนั้น และมีจุดตรวจค้างอย่างไร การรับรองว่าอัปเดตแล้วจึงควรอิงหน้ากับไฟล์ที่ตรวจได้รับจริง
เนื้อหาเก่าหลังแก้บทความอาจค้างอยู่ต่างชั้นกัน การไล่จากต้นฉบับ ผลเรนเดอร์ และ response ที่ผู้ใช้ได้รับ ช่วยให้เลือกจัดการ cache ได้ตรงจุด เมื่อผูกการหมดอายุกับหน้าที่ใช้ข้อมูลร่วมกันและตรวจเนื้อหาจริงหลังเปลี่ยน ก็จะอธิบายสถานะการเผยแพร่ได้ชัดกว่าการยืนยันจากปุ่มบันทึกเพียงอย่างเดียว