🔵 عنوان مقاله
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** الگوی Outbox روشی عملی برای حذف مشکل دونوشتن و تضمین تحویل مطمئن پیامهاست. در این روش، تغییرات دامنه و یک رکورد رویداد در جدول outbox داخل همان تراکنش Postgres ذخیره میشوند؛ سپس یک پردازشگر در Go رویدادها را از جدول خوانده و به پیامرسانهایی مانند Kafka یا RabbitMQ منتشر میکند. با استفاده از فیلدهایی مانند ID، کلید موجودیت، نوع رویداد، payload به صورت JSONB، وضعیت/تعداد تلاش، و زمانها، همگامی داده و پیام تضمین میشود. پردازشگر با انتخاب دستههای کوچک و بهکارگیری SELECT … FOR UPDATE SKIP LOCKED از رقابت جلوگیری کرده، پس از انتشار وضعیت را به «پردازششده» تغییر میدهد و شکستها را با backoff و صف خطا مدیریت میکند. این الگو تحویل حداقل-یکبار را فراهم میکند و با مصرفکنندههای idempotent میتوان به پردازش مؤثرِ یکباره رسید. برای کارایی بهتر، ایندکسگذاری بر status و created_at، پارتیشنبندی جدول، حفظ ترتیب بر اساس کلید موجودیت و نظارت بر عمق صف و تأخیر انتشار توصیه میشود. بهعنوان جایگزین، CDC با منبعخوانی منطقی Postgres (مثلاً Debezium) میتواند بهجای polling استفاده شود، هرچند پیچیدگی عملیاتی بیشتری دارد. با آزمونهای یکپارچه، مدیریت مهاجرتهای شِما و پاکسازی دادههای پردازششده، پیادهسازی در Go و Postgres به پلی پایدار بین پایگاهداده و سامانه پیامرسان تبدیل میشود؛ همان رویکردی که Alex Pliutau در معرفی پیادهسازی Outbox با Go و Postgres بر آن تأکید دارد.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Reliability #Messaging
🟣لینک مقاله:
https://postgresweekly.com/link/174464/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** الگوی Outbox روشی عملی برای حذف مشکل دونوشتن و تضمین تحویل مطمئن پیامهاست. در این روش، تغییرات دامنه و یک رکورد رویداد در جدول outbox داخل همان تراکنش Postgres ذخیره میشوند؛ سپس یک پردازشگر در Go رویدادها را از جدول خوانده و به پیامرسانهایی مانند Kafka یا RabbitMQ منتشر میکند. با استفاده از فیلدهایی مانند ID، کلید موجودیت، نوع رویداد، payload به صورت JSONB، وضعیت/تعداد تلاش، و زمانها، همگامی داده و پیام تضمین میشود. پردازشگر با انتخاب دستههای کوچک و بهکارگیری SELECT … FOR UPDATE SKIP LOCKED از رقابت جلوگیری کرده، پس از انتشار وضعیت را به «پردازششده» تغییر میدهد و شکستها را با backoff و صف خطا مدیریت میکند. این الگو تحویل حداقل-یکبار را فراهم میکند و با مصرفکنندههای idempotent میتوان به پردازش مؤثرِ یکباره رسید. برای کارایی بهتر، ایندکسگذاری بر status و created_at، پارتیشنبندی جدول، حفظ ترتیب بر اساس کلید موجودیت و نظارت بر عمق صف و تأخیر انتشار توصیه میشود. بهعنوان جایگزین، CDC با منبعخوانی منطقی Postgres (مثلاً Debezium) میتواند بهجای polling استفاده شود، هرچند پیچیدگی عملیاتی بیشتری دارد. با آزمونهای یکپارچه، مدیریت مهاجرتهای شِما و پاکسازی دادههای پردازششده، پیادهسازی در Go و Postgres به پلی پایدار بین پایگاهداده و سامانه پیامرسان تبدیل میشود؛ همان رویکردی که Alex Pliutau در معرفی پیادهسازی Outbox با Go و Postgres بر آن تأکید دارد.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Reliability #Messaging
🟣لینک مقاله:
https://postgresweekly.com/link/174464/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
packagemain.tech
How to implement the Outbox pattern in Go and Postgres
How and why to use the Outbox pattern to build a robust event-driven system.
🔵 عنوان مقاله
How Kafka Works (20 minute read)
🟢 خلاصه مقاله:
Apache Kafka یک پلتفرم متنباز پیامرسانی و رویدادمحور است که رکوردهای key-value را در logهای افزایشی و تغییرناپذیر ذخیره میکند. دادهها در topicها سازماندهی و بین partitionها توزیع میشوند تا مقیاسپذیری افقی و پردازش موازی فراهم شود. ترتیب پیامها در هر partition حفظ میشود، و مصرفکنندهها با تکیه بر offset میتوانند بازپخش دقیق داده و بازیابی وضعیت انجام دهند؛ علاوهبر نگهداشت (retention)، log compaction آخرین رکورد هر key را نگه میدارد. کلاستر Kafka معمولاً حداقل سه broker دارد؛ هر partition یک leader و چند follower دارد و با ضریب تکرار پیشفرض 3 همتابی میشود. نوشتنها به leader انجام میشود و followerها همگامسازی میکنند؛ پایداری با تنظیماتی مانند acks=all و مجموعه ISR کنترل میشود. مدل pull در مصرف به مدیریت backpressure کمک میکند و consumer groupها امکان مقیاسپذیری و تحمل خطا را فراهم میسازند. Kafka بهصورت پیشفرض تحویل at-least-once ارائه میدهد و با idempotent producer و تراکنشها به exactly-once میرسد. در معماری مدرن، پروتکل KRaft جایگزین ZooKeeper شده و هماهنگی، انتخابات leader و بازیابی را در خود Kafka متمرکز میکند و عملیات را ساده و سریعتر میسازد.
#ApacheKafka #KRaft #ZooKeeper #DistributedSystems #EventStreaming #Scalability #FaultTolerance #Messaging
🟣لینک مقاله:
https://newsletter.systemdesign.one/p/how-kafka-works?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Kafka Works (20 minute read)
🟢 خلاصه مقاله:
Apache Kafka یک پلتفرم متنباز پیامرسانی و رویدادمحور است که رکوردهای key-value را در logهای افزایشی و تغییرناپذیر ذخیره میکند. دادهها در topicها سازماندهی و بین partitionها توزیع میشوند تا مقیاسپذیری افقی و پردازش موازی فراهم شود. ترتیب پیامها در هر partition حفظ میشود، و مصرفکنندهها با تکیه بر offset میتوانند بازپخش دقیق داده و بازیابی وضعیت انجام دهند؛ علاوهبر نگهداشت (retention)، log compaction آخرین رکورد هر key را نگه میدارد. کلاستر Kafka معمولاً حداقل سه broker دارد؛ هر partition یک leader و چند follower دارد و با ضریب تکرار پیشفرض 3 همتابی میشود. نوشتنها به leader انجام میشود و followerها همگامسازی میکنند؛ پایداری با تنظیماتی مانند acks=all و مجموعه ISR کنترل میشود. مدل pull در مصرف به مدیریت backpressure کمک میکند و consumer groupها امکان مقیاسپذیری و تحمل خطا را فراهم میسازند. Kafka بهصورت پیشفرض تحویل at-least-once ارائه میدهد و با idempotent producer و تراکنشها به exactly-once میرسد. در معماری مدرن، پروتکل KRaft جایگزین ZooKeeper شده و هماهنگی، انتخابات leader و بازیابی را در خود Kafka متمرکز میکند و عملیات را ساده و سریعتر میسازد.
#ApacheKafka #KRaft #ZooKeeper #DistributedSystems #EventStreaming #Scalability #FaultTolerance #Messaging
🟣لینک مقاله:
https://newsletter.systemdesign.one/p/how-kafka-works?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
newsletter.systemdesign.one
How Kafka Works
#91: Learn Everything About Apache Kafka’s Architecture, Including Brokers, KRaft, Topic Partitions, Tiered Storage, Exactly Once, Kafka Connect, Kafka Schema Registry and Kafka Streams
🎉1