🔵 عنوان مقاله
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
🔵 عنوان مقاله
"You Don't Need Kafka, Just Use Postgres" Considered Harmful
🟢 خلاصه مقاله:
** گونار مورلینگ به ادعای «You Don’t Need Kafka, Just Use Postgres» پاسخ می‌دهد و می‌گوید این توصیه اگر به‌صورت کلی پذیرفته شود گمراه‌کننده و مضر است. به‌زعم او، جایگزین‌کردن یک لاگ توزیع‌شده با یک پایگاه‌داده رابطه‌ای، تفاوت اساسی میان «event streaming» و «OLTP» را نادیده می‌گیرد: Kafka تضمین‌هایی مثل نگهداری رویدادها، ترتیب‌پذیری، قابلیت replay، fan-out مستقل و مدیریت backpressure ارائه می‌کند که Postgres ذاتاً برای آن ساخته نشده است. البته در مقیاس‌های کوچک و سناریوهای ساده، انتخاب Postgres می‌تواند کافی و ساده‌تر باشد؛ اما با رشد سیستم و نیاز به جداسازی سرویس‌ها و replay تاریخی، محدودیت‌ها آشکار می‌شوند. مورلینگ الگوهایی مثل outbox و CDC (با ابزارهایی مانند Debezium) را برای پیوندزدن دنیای تراکنشی Postgres با جریان رویداد در Kafka توصیه می‌کند. جمع‌بندی او: نسخه‌های کلی «فقط از X استفاده کنید» خطرناک‌اند؛ نیازها را دقیق تحلیل کنید و براساس مبادله‌های واقعی ابزار مناسب یا ترکیب ابزارها را برگزینید.
#Kafka #Postgres #EventStreaming #CDC #Debezium #SoftwareArchitecture #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/176683/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
"You Don't Need Kafka, Just Use Postgres" Considered Harmful
🟢 خلاصه مقاله:
** گونار مورلینگ به ادعای «You Don’t Need Kafka, Just Use Postgres» پاسخ می‌دهد و می‌گوید این توصیه اگر به‌صورت کلی پذیرفته شود گمراه‌کننده و مضر است. به‌زعم او، جایگزین‌کردن یک لاگ توزیع‌شده با یک پایگاه‌داده رابطه‌ای، تفاوت اساسی میان «event streaming» و «OLTP» را نادیده می‌گیرد: Kafka تضمین‌هایی مثل نگهداری رویدادها، ترتیب‌پذیری، قابلیت replay، fan-out مستقل و مدیریت backpressure ارائه می‌کند که Postgres ذاتاً برای آن ساخته نشده است. البته در مقیاس‌های کوچک و سناریوهای ساده، انتخاب Postgres می‌تواند کافی و ساده‌تر باشد؛ اما با رشد سیستم و نیاز به جداسازی سرویس‌ها و replay تاریخی، محدودیت‌ها آشکار می‌شوند. مورلینگ الگوهایی مثل outbox و CDC (با ابزارهایی مانند Debezium) را برای پیوندزدن دنیای تراکنشی Postgres با جریان رویداد در Kafka توصیه می‌کند. جمع‌بندی او: نسخه‌های کلی «فقط از X استفاده کنید» خطرناک‌اند؛ نیازها را دقیق تحلیل کنید و براساس مبادله‌های واقعی ابزار مناسب یا ترکیب ابزارها را برگزینید.
#Kafka #Postgres #EventStreaming #CDC #Debezium #SoftwareArchitecture #Scalability
🟣لینک مقاله:
https://postgresweekly.com/link/176683/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
www.morling.dev
"You Don't Need Kafka, Just Use Postgres" Considered Harmful
Looking to make it to the front page of HackerNews? Then writing a post arguing that "Postgres is enough", or why "you don’t need Kafka at your scale" is a pretty failsafe way of achieving exactly that. No matter how often it has been discussed before, this…