Actionbase – ฐานข้อมูลสำหรับไลก์ รายการที่ดูล่าสุด และการติดตาม

 (github.com/kakao)
35 คะแนน โดย em3ss 2026-01-28 | 24 ความคิดเห็น | แชร์ทาง WhatsApp

เราได้เปิดซอร์สฐานข้อมูล Actionbase สำหรับฟีเจอร์อย่างไลก์ สินค้าที่ดูล่าสุด และการติดตามเป็นโอเพนซอร์สแล้ว

สวัสดีครับ ผมเป็นนักพัฒนาที่ร่วมสร้าง Actionbase อยู่ที่ Kakao

เมื่อคืนเวลา 20:00 น. (วันที่ 27) เราได้นำ Actionbase ไปโพสต์บน Hacker News (Show HN) และภายในเวลาประมาณ 1 ชั่วโมง 30 นาทีหลังโพสต์ ก็ขึ้นอันดับ 1 ของหน้าแรก เป้าหมายจริง ๆ แค่หวังว่าจะติดอยู่บนหน้าแรกได้ แต่ผลตอบรับดีกว่าที่คาดไว้

ทำไมถึงสร้างมันขึ้นมา?

ฟีเจอร์อย่างไลก์ สินค้าที่ดูล่าสุด หรือการติดตาม แม้แต่ละบริการจะมีรายละเอียดต่างกันเล็กน้อย แต่ก็มักต้องสร้างโครงสร้างข้อมูลและวิธีประมวลผลที่คล้ายกันซ้ำ ๆ

ปัญหาคือแต่ละทีมมักจะทำรายการแบบเดินหน้า/ย้อนกลับ, count และ index แตกต่างกันไปเล็กน้อย วิธีจัดการ retry หรือการเรียงลำดับเหตุการณ์ก็ไม่เหมือนกัน ทำให้บางครั้งข้อมูลคลาดเคลื่อนกันแบบละเอียด ๆ และวิธีสร้างข้อมูลสรุปอย่างจำนวนไลก์ก็แตกต่างกันไป จนดูแลระบบได้ยาก

มันทำงานอย่างไร?

Actionbase นิยามสิ่งนี้เป็นโมเดลความสัมพันธ์แบบ ใคร (actor) ทำอะไร (action) กับอะไร (target) และคำนวณทุกอย่างล่วงหน้าตั้งแต่ตอนเขียนข้อมูล การอ่านจึงเป็นเพียงการดึงข้อมูลธรรมดา ทำให้เร็วและคาดเดาได้

การใช้งานจริงในโปรดักชัน

การใช้งานจริงครั้งแรกในโปรดักชันคือ KakaoTalk Gift Wish ตอนนั้นยังมีหลายจุดที่ไม่สมบูรณ์ แต่เพื่อให้ตอบโจทย์ความคาดหวัง เราได้ปรับปรุงหลายอย่าง และประสบการณ์นั้นก็กลายเป็นแรงผลักดันให้โปรเจกต์เติบโต

👉 ดูเรื่องราว

ปัจจุบัน หลายบริการของ Kakao ใช้งานมันเพื่อรองรับคำขอมากกว่า 1 ล้านรายการต่อนาที มาเป็นเวลาหลายปีแล้ว ที่เก็บข้อมูลใช้ HBase เป็นพื้นฐาน และกำลังเตรียมสตอเรจแบบน้ำหนักเบา (บนพื้นฐาน SlateDB) เพื่อรองรับระบบในหลายขนาด

เริ่มต้นใช้งาน

สามารถลองรันได้ทันทีด้วย Docker:

docker run -it ghcr.io/kakao/actionbase:standalone

ยินดีรับทั้งคำถาม ฟีดแบ็ก และดาวครับ

ด้วยความเคารพจาก @em3s, @zipdoki, @eazyhozy

Q&A

Q: ใช้ Redis ก็ได้ไม่ใช่หรือ?

ได้ครับ เราเองก็ใช้ Redis เป็นแคชสำหรับ hot data เช่นกัน แต่เมื่อระบบขยายใหญ่ขึ้น เราพบปัญหาที่แต่ละทีมต้องทำซ้ำเอง และเมื่อการเรียงลำดับเหตุการณ์ผิดเพี้ยน ข้อมูลก็เริ่มไม่ถูกต้อง

Q: แค่ทำ sharding บน PostgreSQL/MySQL ก็พอไม่ใช่หรือ?

หลายทีมก็ทำแบบนั้น ปัญหาที่เราเจอคือ hot entity, การอ่านข้อมูลข้าม shard และกลยุทธ์ cache ที่ต่างกันในแต่ละบริการ เราต้องการโมเดลที่ขยายแนวนอนได้โดยไม่ต้องออกแบบกลยุทธ์ sharding ใหม่ทุกครั้ง

Q: Write-time precompute ทำงานอย่างไร?

ตอนเขียนข้อมูลจะทำ WAL write → lock → state transition → คำนวณ count/index → save → publish CDC ส่วนการอ่านทำแค่ GET หรือ SCAN เดียวก็พอ

Q: ถ้าลำดับเหตุการณ์สลับกันล่ะ?

แต่ละ mutation จะมี version (โดยทั่วไปคือตัวประทับเวลา) กำกับไว้ แม้อีเวนต์จะมาถึงในลำดับ like(t=100) → like(t=300) → unlike(t=200) สถานะสุดท้ายก็จะลู่เข้าสู่ค่าที่ถูกต้องตาม version เป้าหมายคือแม้จะ replay อีเวนต์เดิมซ้ำ ก็ยังลู่เข้าสู่สถานะเดียวกัน

Q: ประสิทธิภาพจริงเป็นอย่างไร?

ในโปรดักชันของ KakaoTalk Gift รองรับได้ต่อเนื่องมากกว่า 1 ล้านรายการต่อนาที และพีคราว 2 ล้านรายการ ความหน่วงในการอ่านอยู่ที่ p50 ประมาณ 2~3ms, p99 ประมาณ 10ms ประเด็นสำคัญไม่ใช่ตัวเลขสัมบูรณ์ แต่คือความหน่วงมีขอบเขตที่ควบคุมได้ การอ่านไม่ใช่การ aggregate แต่เป็นการ lookup จากค่าที่คำนวณไว้ล่วงหน้า ดังนั้นแม้ข้อมูลจะโตขึ้น ประสิทธิภาพก็ไม่ลดลง

Q: เหมาะกับ use case แบบไหน?

ไลก์/รีแอ็กชัน, การติดตาม/ผู้ติดตาม และสินค้าที่ดูล่าสุด คือ use case หลัก ส่วนฟีเจอร์ recommendation/ML สามารถใช้ CDC เพื่อส่งข้อมูลสำหรับเทรนได้ แต่ไม่ได้มีไว้สำหรับเสิร์ฟ recommendation โดยตรง สำหรับข้อความแชตอาจไม่ใช่ตัวเลือกที่ดีที่สุด เพราะต้องการรูปแบบการเข้าถึงอื่น เช่น pagination, search และ threading ส่วนตะกร้าสินค้าอีคอมเมิร์ซก็ต้องใช้ transaction แต่ Actionbase ไม่รองรับ cross-edge transaction

Q: มันไม่ overengineering ไปหน่อยหรือ? / ไม่ได้จำเป็นเฉพาะบริษัทใหญ่หรือ?

ก็อาจจะใช่ครับ พูดตรง ๆ ถ้าระบบยังขนาดเล็ก PostgreSQL + Redis ที่จูนมาดีก็มักเป็นคำตอบที่เหมาะกว่า ปัญหาที่ Actionbase แก้—ความซับซ้อนของ sharding, การทำ cache invalidation, และงานซ้ำซ้อนระหว่างทีม—มักจะโผล่ขึ้นมาเมื่อระบบมีขนาดมากพอ หรือมีหลายทีมสร้างฟีเจอร์คล้ายกัน เราสร้างมันขึ้นมาเพราะเจอกำแพงนี้หลายครั้ง และเพื่อให้ใช้ได้แม้กับระบบขนาดเล็ก เราก็กำลังเตรียม lightweight backend (SlateDB) อยู่เช่นกัน

👉 เข้าร่วม Discussion

บทความที่เกี่ยวข้อง

24 ความคิดเห็น

 
hmmhmmhm 2026-01-28

โอ้โห... จะรอติดตามเวอร์ชันแบ็กเอนด์แบบน้ำหนักเบาด้วยนะ!!
 
em3ss 2026-01-29

ขอบคุณครับ! สำหรับแบ็กเอนด์แบบเบา ๆ ผมวางทิศทางไว้แล้วว่าจะใช้ SlateDB ที่ต้องมีแค่ S3 ก็พอ แต่ยังไม่ได้เริ่มอย่างจริงจังครับ

อยากทราบว่าคุณตั้งใจจะใช้ในสภาพแวดล้อมแบบไหนครับ โปรเจกต์ส่วนตัว? โปรดักชันขนาดเล็ก? ผมอยากใช้เป็นข้อมูลอ้างอิงในการจัดลำดับความสำคัญครับ

ถ้ามีเวลา รบกวนช่วยโหวต HBase/SlateDB ด้วยนะครับ ความเห็นจากคอมมูนิตี้น่าจะช่วยในการกำหนดทิศทางได้: https://github.com/kakao/actionbase/discussions/144
 
honglu 2026-01-28

ผมคิดว่านี่เป็นโปรเจกต์ที่ใช้งานได้จริงมาก

ยอดเยี่ยมมาก!
 
em3ss 2026-01-28

ขอบคุณครับ! ผมกำลังมาปลดปล่อยความค้างคาใจจากความสนใจที่ไม่ได้รับใน Show HN ที่นี่ครับ

ผมอยากรู้ว่าคุณรู้สึกว่าส่วนไหนใช้งานได้จริงบ้าง คุณเคยเจอปัญหาคล้าย ๆ กันไหม? หรืออยู่ในสถานการณ์ที่ต้องทำฟีเจอร์นั้นพอดี?

แล้วก็พอมีโอกาสได้คอมเมนต์ เลยอยากพูดไว้ว่า ในเอกสารเราเขียนไว้ว่าจะไม่ทำ unbounded traversal แต่ bounded multi-hop อยู่ในแผนของปีนี้ครับ เช่นคิวรีแบบ 2-hop อย่าง "สินค้าที่เพื่อนชอบ" https://actionbase.io/ko/stories/unified-graph/
 
honglu 2026-01-28

สิ่งที่ผมรู้สึกว่าใช้งานได้จริงคือ

ตัวผมเองก็เคยมีประสบการณ์ที่กังวลคล้าย ๆ กันมาก่อน และเคยลองทำ abstraction layer ในระดับโค้ดโดยอิงกับ KV store อย่าง Redis มาก่อนด้วย จึงคิดว่าเป้าหมายและแนวทางที่เอกสารต้องการสื่อ รวมถึงโครงสร้างโดยรวม ล้วนใช้งานได้จริงมาก

และผมคิดว่าการรวบรวมความต้องการและโจทย์ของหลายทีมเข้าด้วยกัน สร้างเป็นผลิตภัณฑ์ภายในของบริษัท แล้วเปิดเผยเป็นโอเพนซอร์ส เป็นเรื่องที่ยอดเยี่ยมมากครับ

สุดท้ายถ้าจะขอเสริมอีกสักนิด สำหรับคนที่จะนำไปใช้ ตอนนี้ตัวเอกสารเองก็เพียงพอแล้ว แต่ผมคิดว่าถ้ามีตัวอย่างการ deploy ที่ทำตามได้ในระดับคัดลอก-วาง รวมถึงใส่ use case ที่แนะนำหรือ infrastructure reference ที่แนะนำไว้ใน example ด้วย ก็น่าจะทำให้น่าสนใจยิ่งขึ้น

สู้ ๆ ครับ!
 
em3ss 2026-01-28

โอ้ ดีใจจากใจจริงที่ได้รู้ว่าคุณก็เคยมีความกังวลแบบเดียวกัน และขอบคุณจากใจจริงที่ชื่นชมว่ามันยอดเยี่ยม

ผมเห็นด้วยกับประเด็นที่คุณพูดครับ เพราะตัวผมเองก็อยากตั้งค่าส่วนที่ใช้เป็นเครื่องมือได้อย่างสะดวก แล้วโฟกัสกับปัญหาที่ผมต้องแก้

อย่างไรก็ตาม ตอนนี้ยังอยู่ในช่วงเริ่มต้นของโอเพนซอร์ส และเรามุ่งเน้นว่าจะสื่อสารคุณค่าหลักนี้อย่างไรภายในเวลาที่จำกัด เพราะถ้าสื่อสารออกไปไม่ถึง คนที่จริง ๆ แล้วสามารถนำไปใช้แก้ปัญหาได้ก็อาจทำไม่ได้เช่นกัน จากนี้ไปเราตั้งใจจะเดินหน้าในทิศทางที่คุณพูดถึง แต่ก็อยากรับฟังฟีดแบ็กว่าควรไปทางสแตกภายในอย่าง HBase + Kafka หรือแม้จะต้องลงแรงพัฒนาใหม่ก็ควรไปทาง SlateDB + S2 ดี เพราะฝั่งเรามีวิศวกร HBase ช่วยดูแลการปฏิบัติการอยู่จึงใช้งานได้ค่อนข้างสะดวก แต่หลายที่อาจไม่ได้เป็นแบบนั้น หากช่วยฝากความเห็นไว้จะขอบคุณมากครับ (อย่างน้อยกดโหวตก็ยังดี):

https://github.com/kakao/actionbase/discussions/144
 
honglu 2026-01-28

ผมคิดว่าโรดแมปอย่างคิวรีแบบ 2-hop ที่คุณพูดถึงก็น่าสนใจมากเช่นกัน

แต่ผมคิดว่าถ้าถ่ายทอดประเด็นที่เอกสารปัจจุบันต้องการสื่อออกมาให้ดีด้วยตัวอย่างอย่างโค้ด ก็น่าจะได้รับการตอบรับอย่างถล่มทลายมากกว่านี้ครับ
 
em3ss 2026-01-28

เห็นด้วยครับ เรื่อง "การถ่ายทอดออกมาผ่านตัวอย่างให้ดี" แต่พอทำจริงแล้วมันไม่ได้ง่ายอย่างที่เห็นเลย T_T จะลองคิดและพิจารณาในหลาย ๆ ด้านดูครับ ขอบคุณครับ!

ไม่แน่ใจว่าคุณได้ดูอินเทอร์แอกทีฟไกด์ที่เพื่อนร่วมทีมของเราตั้งใจเตรียมไว้ที่ https://actionbase.io/guides/build-your-social-media-app/ หรือยังนะครับ นี่ก็เป็นความพยายามในแนวทางนั้นเหมือนกัน ทำให้เราได้ย้อนมองว่ามันสอดคล้องกับทิศทางที่คุณพูดถึงไหม จะพยายามต่อไปครับ.
 
honglu 2026-01-28

อ้อ แล้วก็เป็นจุดที่เพิ่งสังเกตเห็นหลังจากคอมเมนต์ใหม่ เลยพลาดไปก่อนหน้านี้ คือไม่ใช่แค่ไกด์เท่านั้น แต่โดยรวมแล้วสัมผัสได้ว่ามีความตั้งใจกับการจัดโครงสร้างเอกสารมาก

แต่ถ้าสามารถทำให้ชุดคอนฟิกที่เตรียมไว้เป็นตัวอย่าง ให้คนตามได้ง่ายผ่าน git clone อย่างที่ได้กล่าวไปก่อนหน้านี้ ก็น่าจะดียิ่งขึ้นครับ
 
em3ss 2026-01-29

ผมจะตอบไปพร้อมกันในคอมเมนต์ด้านล่างครับ
 
honglu 2026-01-28

ผมนึกว่าคอมเมนต์ไปแล้ว แต่ไม่เห็นขึ้น เลยเขียนใหม่ตั้งแต่ต้นเลย...(ฮือ)
ทั้งที่เป็นคอมเมนต์ที่เขียนแบบสบาย ๆ แต่ก็ยังตอบกลับมาอย่างใส่ใจมาก ขอบคุณครับ.. 555;;

อย่างไรก็ตาม สิ่งที่ผมอยากจะบอกก็คือ ผมคิดว่าสภาพแวดล้อมของทั้งทีมเล็ก ๆ หรือทีมใหญ่ที่อยากลองนำสิ่งนี้ไปใช้ น่าจะแตกต่างกันมาก และถ้าคิดแบบสบาย ๆ ว่า ลองเอาสิ่งนี้มาใช้ดูไหม? รูปแบบที่น่าจะโน้มน้าวได้ง่ายที่สุด ก็คือโปรเจกต์ตัวอย่างที่เขียนด้วยภาษาที่ทีมใช้อยู่ครับ

ถ้าสร้างโปรเจกต์ตัวอย่างด้วยภาษายอดนิยมก่อน แล้วจัดทำ quick start โดยอิงจากสิ่งนั้น ก็น่าจะทำให้อ่านได้แบบสบายใจกว่ามาก และผมคิดว่าความน่าสนใจอยู่ที่การ git clone แล้วลองได้ทันทีแบบคลิกเดียวครับ

และผมก็คิดว่าวิธีนี้เป็นวิธีที่ดีที่สุดในการอธิบาย best practice ด้วยครับ

แน่นอนว่าผมรู้ว่า ด้วยลักษณะของโปรเจกต์ การทำแบบนั้นคงไม่ง่ายนัก แต่ถึงอย่างนั้นผมก็ยังคิดว่านั่นเป็นสิ่งที่น่าสนใจที่สุดครับ

อีกอย่าง ถ้าเป็นไปได้ ผมคิดว่าน่าจะดียิ่งขึ้นถ้าจัดทำตัวอย่างร่วมกับเครื่องมืออย่าง pulumi หรือ terraform ด้วยครับ
 
em3ss 2026-01-29

เป็นมุมมองที่ไม่เคยนึกถึงมาก่อนเลย ขอบคุณมากจริงๆ สำหรับข้อเสนอแบบนี้ นี่เป็นประสบการณ์ดีๆ ที่ได้รับจากคอมมูนิตี้

ผมจะลองคิดดูว่าจะทำให้แนวทางที่คุณพูดถึงเกิดขึ้นจริงได้อย่างไร รวมถึงตัวอย่าง pulumi หรือ terraform ด้วย บางทีอาจจะเป็นการจัดทิศทางให้ชัดเจนแล้วขอการสนับสนุนจากคอมมูนิตี้ก็ได้ ถ้าถึงตอนนั้นคุณมาร่วมช่วยด้วยก็จะยิ่งขอบคุณมากครับ

เพิ่มเติมคือ ตอนนี้ผมกำลังคิดอยู่ว่าในยุคของ vibe coding จะทำอย่างไรให้สิ่งนี้กลายเป็นพื้นฐานได้ เวลาพูดว่า "ช่วยสร้างแอปพลิเคชันให้หน่อย" ก็จะเขียนด้วย React, Svelte และอื่นๆ ใช่ไหมครับ อยู่ในตำแหน่งแบบเดียวกันนั้น คือเวลาพูดว่า "ช่วยเพิ่มฟีเจอร์ไลก์ให้หน่อย" แล้ว Actionbase เป็นตัวที่ทำหน้าที่นั้น

ประเด็นนี้ก็ยังวนอยู่ในหัวผมตลอดเหมือนกัน เพราะแบบนั้นจึงใส่ใจกับการทำเอกสารอย่างมากเพื่อให้เครื่องมือ AI อ่านได้ และช่วงหลังก็เริ่มเห็นความเป็นไปได้แล้วด้วย

อ้างอิง:

llms.txt - https://actionbase.io/llms-txt/
ลองทำสูตรของผู้ชนะ Anthropic Hackathon - https://github.com/kakao/actionbase/discussions/90
 
ethanhur 2026-01-28

ดูเหมือนว่าน่าจะนำไปใช้ได้ดีในที่ที่มี use case คล้ายกัน ขอบคุณที่เปิดเผยให้ใช้งานครับ!

อย่างไรก็ตาม ผมสงสัยว่าในส่วนที่ใช้ Lock ตอน ingestion มีปัญหาอะไรบ้างไหมครับ ในกรณีของการเขียนข้อมูล มีทราฟฟิกอยู่ประมาณระดับไหน? แล้วเคยมีกรณีที่เกิดปัญหาจากการแย่ง Lock กันหรือไม่ครับ?
 
em3ss 2026-01-28

ขอบคุณสำหรับคำถามดี ๆ ครับ!

Lock จะถูกจับในระดับคู่ edge (source, target) (เช่น Alice→Phone) การแข่งขันกันจะเกิดขึ้นเฉพาะเมื่อมีการเขียนลง edge เดียวกันพร้อมกันเท่านั้น แต่ในทางปฏิบัติแทบไม่มีกรณีที่ผู้ใช้คนเดียวกันจะกดไลก์เป้าหมายเดียวกันพร้อมกัน จึงมีการแข่งขันต่ำ นี่คือคุณลักษณะของยูสเคสฐานข้อมูลของเรา

ทราฟฟิกการเขียนที่จุดพีกอยู่ที่ระดับหลายแสนรายการต่อนาที การอ่านอยู่ที่ 1 ล้าน+ และการเขียนต่ำกว่านั้น
ดูเบนช์มาร์กได้ที่ (อ่าน 85%, เขียน 15%) - https://actionbase.io/ko/operations/benchmarks/

Hot entity (เช่น สินค้ายอดนิยม) อาจเกิด lock contention ได้ ซึ่งเป็นเพราะการอัปเดต count (HBase Increment) เราจัดการส่วนนี้ด้วยการปรับแต่งแยกต่างหากไว้แล้ว
เกี่ยวกับการเขียนความถี่สูง: https://actionbase.io/ko/stories/kakaotalk-gift-recent-views/
 
ifmkl 2026-01-28

โอ.....
 
em3ss 2026-01-28

ขอบคุณครับ! หากสนใจ รบกวนช่วยฝากความเห็นเกี่ยวกับทิศทางถัดไปได้ที่: https://github.com/kakao/actionbase/discussions/144
 
kissdesty 2026-01-28

ว้าว อันนี้ดูมีประโยชน์มากเลยครับ
 
em3ss 2026-01-28

ขอบคุณครับ! อยากทราบเหมือนกันว่าระหว่างที่พัฒนาฟีเจอร์คล้ายกันนี้ คุณเคยเจอปัญหาอะไรบ้างไหม ตอนนี้เรากำลังรับฟังความคิดเห็นจากคอมมูนิตี้ว่าอะไรควรเป็นสิ่งถัดไปที่เราจะทำก่อน: https://github.com/kakao/actionbase/discussions/144
 
winterjung 2026-01-28

เอกสารสำหรับนักพัฒนาเขียนไว้ได้ดีมากจริงๆ ครับ use case ที่แสดงผ่าน stories รวมถึง quick start และ faq ก็อัดแน่นเสียจนเรียกได้ว่าอยู่ในระดับเดียวกับบล็อกเทคนิคเลยครับ
 
em3ss 2026-01-29

ว้าว ขอบคุณมากจริงๆ ครับ หลังจากโอเพนซอร์สเมื่อวันที่ 5 มกราคมจนถึงการเปิดให้ชุมชนใช้งานในวันที่ 27 เราทุ่มเทกับเอกสารไปมาก เลยดีใจที่มีคนมองเห็น

เพราะเป็นช่วงเริ่มต้นของโอเพนซอร์ส เราเลยโฟกัสกับคำถามว่า "นี่คืออะไร และทำไมถึงจำเป็น" เลยคิดว่าน่าจะออกมาเป็นผลลัพธ์แบบนี้ครับ หากลองอ่านเอกสารแล้วมีจุดไหนที่ยังน่าเสียดายหรือขาดไป บอกกันได้สบายๆ เลย!

อีกอย่าง ถ้าใช้ https://actionbase.io/llms-txt/ คุณอาจได้ผลลัพธ์ที่คาดไม่ถึงก็ได้ครับ ช่วงนี้พอเห็นคนที่ยังไม่ค่อยรู้จัก Actionbase ใช้พรอมป์ต์นี้เพื่อไปให้ถึงข้อสรุปที่เหมาะสมที่สุดสำหรับความต้องการที่ซับซ้อน ก็ยิ่งรู้สึกอีกครั้งว่าโลกเปลี่ยนไปแล้วจริงๆ

ลองใช้ข้อความต่อไปนี้ใน ChatGPT, Claude, Gemini ฯลฯ ดูได้เลย

Read https://actionbase.io/_llms-txt/core.txt  
  
You are an assistant answering questions about Actionbase.  
Answer using only the provided Actionbase documentation.  
If the documentation does not specify the answer, say so explicitly.  
  
{คำถาม}
 
em3ss 2026-01-28

น่าสงสัยได้ครับ แต่ไม่ได้ปั่นนะครับ

ผมใส่ลิงก์ 4 อันไว้ในคอมเมนต์แรก แล้วโดน shadowban อยู่ 30 นาที ช่วงนั้นคำอธิบายบริบทมันไม่แสดง คนก็เลยผ่านไปเฉย ๆ ตอนนั้นกังวลมากครับ กลัวโพสต์จะจมหาย พอเอาลิงก์ออกแล้วคอมเมนต์ใหม่ ถึงค่อยขึ้นไปอันดับ 1 แล้วก็เริ่มมีคอมเมนต์ตามมาด้วย

คอมเมนเตอร์คนนั้นที่คุณพูดถึง ผมก็เช็กแล้วครับว่าเพิ่งสมัครมาได้ไม่นาน แต่ก็ยังรู้สึกขอบคุณนะครับ อย่างน้อยก็ยังมีคนตอบสนองบ้าง เลยตั้งใจตอบกลับไปอย่างดี คำถาม "why not redis?" ผมเตรียมไว้ล่วงหน้าเลยครับ เป็นคำถามที่ถ้าเกี่ยวกับ DB ยังไงก็ต้องมา ผมคิดด้วยซ้ำว่า เตรียมมาจริงจังขนาดนี้ จะมีคนมาถามแบบนั้นจริงเหรอ แต่เมื่อวันก่อนตอน s2-streamstore ก็ได้รู้แล้วครับ เพราะมีคนตอบมาว่า "ทำผ่าน TCP สิ" ก็เลยเตรียมไว้ครับ

อีกอย่าง ผมขอทีมไว้ชัดเจนว่าอย่ามา upvote/คอมเมนต์เด็ดขาด และให้ล็อกเอาต์ไว้ด้วย เผื่อพลาด HN ค่อนข้างอ่อนไหวกับเรื่องพวกนี้ ผมรู้อยู่ก่อนแล้วครับ

ยังไงก็ตาม ต่อให้ผมอธิบาย คุณอาจจะไม่เชื่อก็ได้... งั้นช่วยดู repo ของพวกเราสักครั้งได้ไหมครับ นี่คือโค้ดที่รอดมาได้ ผมเขียนละเอียดหน่อย เพราะกลัวเพื่อนร่วมงานที่ทำด้วยกันจะเสียใจถ้าเห็นโพสต์นี้ https://github.com/kakao/actionbase/discussions/32 ลองดูสักครั้งนะครับ ขอบคุณครับ

แล้วก็

https://actionbase.io/ko/stories/kakaotalk-gift-wish/ ด้วยครับ ถ้าคุณเคยกังวลเรื่องระบบขนาดใหญ่ เนื้อหานี้น่าจะพอช่วยได้ ผมตั้งใจเขียนไว้อย่างเต็มที่ครับ
 
em3ss 2026-01-28

อ้อ แล้วถ้าดู X ของผมด้านล่างก็น่าจะเห็นว่า อันดับ 1 นั่นคือก่อนมีคอมเมนต์นั้นนะครับ คอมเมนต์นั้นน่าจะถูกโพสต์ตอนที่มันตกไปอยู่อันดับ 2~3 แล้ว ตอนที่ผมหยิบออกมาจากเคส Dujjonku ในพื้นที่กินขนม ก็มีคอมเมนต์เข้ามาพอดี เลยรีบวิ่งไปคอมเมนต์ตอบ หลังจากนั้น 12 ชั่วโมงมันก็ถูกดันตกลงไปถึงอันดับ 30 และตอนนี้อยู่หน้า 2 แล้ว T_T
 
em3ss 2026-01-28

โพสต์ไว้บน X ด้วย: https://x.com/enmskim/status/2016412136482996689