وقتی سفارشی در Postgres عوض میشود، ده سیستم دیگر باید بفهمند: ایندکس جستجو، کش، انبار داده، سرویس نوتیفیکیشن. بهجای اینکه اپلیکیشن به همه خبر بدهد (dual-write خطرناک)، دیتابیس خودش جریان تغییرات را بیرون میدهد — این همان Change Data Capture است.
سه راه گرفتن تغییرات
| روش | ایده | حقیقت تلخ |
|---|---|---|
| Polling | هر چند ثانیه SELECT روی ستون updated_at | رکوردهای حذفشده دیده نمیشوند؛ دو بارهخوانیِ جدول؛ تأخیر |
| Trigger | روی هر تغییر در جدول، رکورد به جدول رویداد بنویس | بار اضافه روی مسیر نوشتن دیتابیس |
| Log-based | خواندن WAL/binlog خودِ دیتابیس و تبدیل به رویداد | استاندارد طلایی: بدون بار روی کوئریها، بدون جاافتادن حتی DELETE |
ابزار مرجع Debezium است: به WAL ی Postgres یا binlog ی MySQL وصل میشود و هر تغییر را بهصورت رویداد در Kafka منتشر میکند. حالا هر مصرفکنندهای — Elasticsearch ،Redis ،Warehouse — با سرعت خودش از منبع حقیقت تغذیه میشود.
سه کاربرد که قبلاً دیدهای و حالا پیوند میخورد
- Outbox relay (فصل ۵): رویداد در جدول outbox مینشیند؛ CDC همان جدول را خوانده و به Kafka میبرد — الگوی Outbox بدون relay دستساز.
- همگامسازی ایندکس جستجو: نوشتن در DB، چند ثانیه بعد در Elasticsearch — سازگاری نهاییِ مهندسیشده بهجای dual-write.
- باطلسازی کش: رویداد تغییر رکورد → حذف کلید متناظر در Redis؛ دقیقتر از TTL حدسی.
- ساخت Read Model برای CQRS: جریان تغییرات، نماهای خواندنی را بهروز نگه میدارد.
ریزنکتهها
- ترتیب: رویدادهای یک رکورد باید مرتب برسند — کلید پارتیشن Kafka را primary key بگذار.
- تغییر schema (افزودن ستون) باید از مسیر CDC هم عبور کند — schema registry (فصل ۱۳) اینجا هم لازم است.
- Snapshot اولیه: قبل از دنبالکردن لاگ، یک dump سازگار از وضعیت فعلی میگیری و بعد به نقطهای از لاگ وصل میشوی.
به زبان ساده
CDC یعنی بهجای اینکه برنامه به چند جا بنویسد، از لاگ تغییرات دیتابیس پخش میکنیم؛ هر تغییر خودبهخود به ایندکس جستجو، کش و انبار داده میرسد.
مثال واقعی
وقتی قیمت کالا در دیتابیس عوض میشود، CDC همان لحظه به Elasticsearch و کش خبر میدهد؛ لازم نیست برنامهنویس یادش باشد سه جا را هماهنگ کند.