Go Casts | Systems & Agents 🚀

سلام رفیق!

دوستان امیدوارم حالتون خوب باشه

برای اینکه ارتباط بهتری باهاتون داشته باشم قصد دارم ان شاءالله در قالب یه خبرنامه در خدمتتون باشم.
لطفا اگه تمایل داشتید در خبرنامه عضو بشید.

فعالیت GoCasts همچنان مثل قبل ادامه خواهد داشت. احتمالا فعالیت !Hey Mate دامنه گسترده تری از دنیای نرم افزار رو ان شاءالله پوشش خواهد داد.

https://heymate.ir/?utm_source=telegram&utm_medium=message&utm_campaign=1

#heymate

@gocasts

سلام به همه دوستان گل، امیدوارم که حالتون خوب باشه

سالروز شهادت امیرالمؤمنین را به محضر مقدس حضرت بقیه الله الاعظم علیه السلام و همه ی شیعیان حضرت تسلیت عرض می کنم.


Interface Pollution

مدت ها به این موضوع فکر کردم. و وقتی این عبارت به فکر میکنم، اولین چیزی که به ذهنم میاد اینه که خب interface pollution معنی عامیانه ش این میشه که الکی الکی برای هر کاری همه جا interface بسازیم.
یه ذره که بیشتر تحقیق کردم دیدم در اصل این قضیه وقتی ایجاد میشه که به قول uncle bob شما اصطلاحا یه سری fat interface دارید. مثلا در نظر بگیرید که شما یه repository interface تعریف کردید، که برای entity های مختلف کاربرد داره و مثلا ۱۵، ۲۰ یا حتی بیشتر متد داره. حالا تصور کنید که یکی از سرویس هاتون که از همین repository استفاده میکنه و فقط ۲، ۳ تا متدش رو فراخوانی میکنه. حالا تصور کنید این سرویس به خاطر مسائل perofrmanceی یا هر چیز دیگه ای میخواد از یه repository دیگه استفاده کنه که مثلا in-memory باشه که latency خواندن و نوشتن داده ها در دیتابیس کمتر بشه. خب اون adapter جدید مجبور میشه الکی الکی متدهایی رو پیاده سازی کنه که لازمشون نداره. در حالیکه اگه interface ها به اندازه و کوچکتر تعریف میشدند، این مشکل نبود. این قضیه با رعایت کردن اصل چهارم SOLID یعنی Interface Segregation Principle قابل حل شدنه.

مثلا ما در پروژه adamak برای هر سرویس یک repository در نظر گرفتیم و با این کار سعی کردیم اصل چهارم SOLID رو رعایت کنیم.
https://severinperez.medium.com/avoiding-interface-pollution-with-the-interface-segregation-principle-5d3859c21013


اما حالا اگه در مورد golang بخوایم صحبت کنیم. نکات دیگه ای هم مهمه که خود من هم گاها رعایتشون نمیکنم. برای اینکه در کدهایی که با زبان Go مینویسید مشکل interface pollution اتفاق نیفته، میشه یه سری کارها کرد
اول اینکه از تعریف کردن interface تا حد امکان بپرهیزید. مگر اینکه پکیج شما واقعا generic-use functions داشته باشه. مثلا تابع Copy یکی از این توابع است. که پکیج io برای آن Writer و Reader را به صورت interface تعریف کرده.

دوم اینکه اگر کاربر یا همان کلاینت های پکیج شما به سطحی از «وارونگی کنترل» یا همان inversion of control احتیاج دارند بهتر است در scope خودشان این کار را انجام دهند. کاری که ما با نوشتن interface هایی مثل store در پروژه adamak انجام می دهیم.
https://github.com/gocastsian/adamak/blob/main/contract/user_store.go

دقت کنید این کار را در scope مرتبط با interactor مورد نظر انجام میدهیم (البته در پکیج contract) و هیچ پکیج خارجی ای را مجبور به expose کردن interface نمیکنیم.
همین قضیه برای تست نوشتن هم صدق می کند. گاها کلاینت ها از شما می خواهند یک interface را در پکیج خود expose کنید که کار mock کردن را برای آنها ساده تر کنید. که در اینجا هم می توان به آنها گفت که کلاینت در scope خودش یک interface تعریف کند که تنها متدهای مورد نیازش را در آن interface قرار می دهد.


type acknowledger interface {
Ack(sub string, id ...string) error
}

type mockClient struct{}

func (c *mockClient) Ack(sub string, id ...string) error {
return nil
}

var acker acknowledger = pubsub.New(...)

acker = &mockClient{} // in the test package


باز دقت کنید که تعریف interface در صورت لزوم توسط پکیج (کلاینت) استفاده کننده در همان scope تعریف می شود و پکیج شما لازم نیست interfaceی را expose کند.
https://rakyll.org/interface-pollution/

البته باید در نظر بگیریم که adamak یک web service هست و شاید مثال زدن از آن برای این قضیه سخت باشه. چون عملا خیلی از پکیج های adamak خودشون کلاینت هستند و پکیج های عمومی کمتر توسعه داده میشه در اینطور سرویس ها.


#interface_pollution #solid #golang
@gocasts

سلام دوستان، امروز یه توضیح خوب و جالب در باره مقایسه زبان های کامپایلری و مفسری خوندم، گفتم با شما هم به اشتراک بذارم.
لزوما هر زبان کامپایلری ای قرار نیست سریعتر از زبان های مفسری باشه هر چند که عموما هست.

مثلا زبان C# یه زبان کامپایلری هست. اما کد شمارو به machine code کامپایل نمیکنه. بلکه به یه زبان میانه که اصطلاحا Common Intermediate Language (CIL) میگن کامپایل میکنه. سپس با استفاده از Common Language Runtime در زمان اجرا کد زبان میانه رو به کد زبان ماشین تبدیل میکنه. که اصطلاحا این کار رو Just-in-Time compile میگن. کاری مشابه به زبان Java. نکته مهم JIT اینه که کد رو کش میکنه. پس در واقع هر چقدر که از اجرای برنامه میگذره، برنامه شما سریعتر میشه!

اما خب زبان های مفسری هم بیکار ننشستن. اونا هم راه حل های خودشون رو دارن برای سریعتر اجرا شدن برنامه، یکی از متدوال ترین راه ها استفاده از compiled libraryهایی هستند که مثلا در زبان C++ نوشته شدن و در زبانی مثلا مثل Python شما فقط از API اون کتابخونه برای فراخوانی کد در زمان اجرا استفاده میکنید، بدون اینکه متوجه بشید این کد در چه زبانی نوشته شده و چطوری اجرا میشه

https://qr.ae/pv28iE

#compiled_language #interpreted_language

@gocasts

🙋‍♂️ سوال
من ۲ تا microservice دارم که یک message broker بینشون هست.
سرویس اول یه worker داره که از یکی از جداول دیتابیس همه event هایی که وضعیت new دارند رو میخونه و داخل broker منتشر میکنه. بعد از انتشارشون وضعیت eventها رو آپدیت میکنه که دیگه ارسال نشن.
سرویس دوم مسئولیت پردازش eventهارو داره.
نگرانی من اینه اگه worker همه eventهارو داخل broker ریخت ولی نتونست وضعیتشون رو بروز کنه تو دیتابیس، خب دفعه بعد مجددا این eventهارو داخل broker میریزه و مشکل بوجود میاد، چیکار کنم؟


⚠️ پاسخ بسیار ناقص و احتمالا پر از غلط بنده
ببین شما باید idempotency رو رعایت کنی بین microservice هات. این خودکفایی یا همون idempotency اینو میگه که وقتی شما message driven کار میکنی سرویس هات باید انتظار اینو داشته باشن که یه unique message رو بیش از یکبار دریافت کنن ولی فقط یکبار proccess کنن. برای message broker ها سه تا service quality وجود داره
at most once delivery
exactly once delivery
at least once delivery

به خاطر همین مشکلات network و delivery و چیزهای دیگه exactly once delivery خیلی کار سختیه، حالت اول و سوم رایج تر بنظر میاد. در حالت at most delivery هر سرویس نهایتا یک بار یه event رو دریافت میکنه، پس اصلا نیاز نیست نگران idempotency باشه و بیشتر به درد بیزینس هایی میخوره که miss شدن یه event مشکلی ایجاد نکنه، مثلا notification های یه سایت خبری
حالت سوم که at least once delivery هست احتمال دریافت یه event بیش از یکبار وجود داره ولی خب تضمین میکنه حتما هر consumer یکبار اون event خاص رو حداقل دریافت میکنه.
در مورد چالش شما، شما حالت سوم رو لازم دارید، پس سرویس مقصد باید انتظار داشته باشه یه مسیج رو حتی چندبار دریافت کنه به خاطر مشکلاتی که گفتید، و این طبیعیه و مشکلی نداره. سمت سرویس consumer باید مثلا id پیام و job های process شده رو ذخیره کنه و با دریافت هر پیام جدید چک کنه آیا این پیام قبلا پردازش شده یا نه، اگه پردازش نشده بود پردازشش کنه.
اینطوری سرویس publisher دیگه نگران این نیست حالا اگه message تو broker رفت و جدول دیتابیس آپدیت نشد چی میشه، هیچی نمیشه، یه بار اضافه تر یه سری پیام رو میریزه تو broker که مشکلی نیست.
ضمنا یه سری broker ها مفهوم message deduplication دارن که برای اون حالت exactly once به کار میاد، اینطوریه که خود broker میاد id پیام های ریخته شده در broker رو نگه میداره (حتی تا مدتی بعد از consume شدنشون)، اینطوری اگه مجددا همون message رو با id تکراری بهش بدی خودش متوجه میشه و ignoreش میکنه

در مورد transactional outbox و idempotency و message deduplication سعی کن یه مطالعه ای داشته باشی، مرسی

https://segment.com/blog/exactly-once-delivery/

این پادکست هم شنیدنش شاید کمک کنه
Eventually consistent (managing data at scale)
https://changelog.com/gotime/206

#qa #distributed_systems

@gocasts

سلام به همه دوستان گل

پیشاپیش شهادت علی علیه السلام تسلیت باد
برای بنده علی (ع) یگانه اسوه مردانگی ست. زبانم قاصر است از گفتن آنچه که شایسته اوست. تنها یک قلب آکنده از عشق علی دارم و دیگر هیچ.
هرآنچه که از اخلاق و مردانگی سراغ دارید در علی (ع) جمع است. پدری بینظیر برای همه یتیمان. شیر مردی که تیغ شمشیرش فقط گلوی ظالمین را می برد. عالمی خردمند و در نهایت از عدلش نگویم که بهترین کتاب عدالت است.

برای کل زندگیم فقط این آرزو را دارم که بتوانم دست یتیمی از یتیمان علی (ع) را بگیرم. در این راه اگر یتیمی را می شناسید (نوجوان، جوان) که می توان به او برنامه نویسی آموخت، بنده خاک پایتان هستم برای معرفی ایشان

سلام به همه عزیزان

ولادت امام حسن مجتبی علیه السلام هم مبارک 🌹❤️

دوستانی که در طول تقریبا یکسال گذشته همراه بنده بودند در جریان هستند که بنده اهل تبلیغ و تبادل کانال و ازین جور داستان ها نیستم. الان هم کاملا یهویی تصمیم گرفتم کانال دوستم ایمان جان غفوری رو بهتون معرفی کنم.
من خودم تجربه خاصی در دنیای open-source ندارم، و اگه بخوام بین همه نقاط ضعفم یکی شون رو bold کنم همین موضوعه. نه فقط برای اینکه تو رزومه م نشون بدم، بلکه به این دلیل که واقعا به آدم اعتبار میبخشه و خود آدم به توانمندی هاش ایمان میاره، چرا که مشارکت کردن در پروژه های متن باز مطرح دانش عمیق لازم داره و رسیدن به این نقطه خیلی حس خوبی داره.
لطفا بر خلاف من مشارکت کردن در پروژه های متن باز رو جدی بگیرید.

ایمان جان جز بهترین افراد ایرانی هست که روی پروژه لاراول خیلی contribute داره و چندین تا پلاگین خوب هم برای لاراول نوشته. با اینکه هیچوقت علاقه ای به php نداشتم ولی واقعا احترام زیادی براشون قائلم. لقب web artisans به حق مناسبشونه. نه تنها php/laravel، بلکه ruby on rails و python/django و جدیدا elixir/phoenix هم به همچنین. خیلی اوقات چالشی که برای ما در گولنگ خیلی حل کردنش سخته، در فریمورک های مذکور بهترین راه حل ها براش ارائه شده.
بشدت پیشنهاد میکنم حتما سعی کنید باهاشون آشنا بشید و کمی در مورد best practice هاشون بخونید. فارغ از اینکه دید مهندسی نرم افزار خیلی بهتری میگیرید، ممکنه یه روزی به کارتونم بیاد. چون خیلی از شرکت های بزرگ چه داخلی، چه خارجی احتمالا یه سری از legacy project هاشون با یکی از این فریمورک ها هست و وقتی وارد شرکت می‌شید دونستن این موارد مزیت محسوب میشه.

اینم کانال آقا ایمان
https://t.me/codino

در مورد ایمان جان، میتونید اینجا کامیت های مرج شده ش روی لاراول رو ببینید.
https://github.com/laravel/framework/pulls?q=is%3Apr+is%3Amerged+author%3Aimanghafoori1+


من خودم بعضی از دوره هاشو خریداری کردم، نه فقط به خاطر اینکه php یاد بگیرم، بلکه بیشتر به خاطر اینکه بفهمم best practice ها در لاراول چیه و کدومشون رو میتونم استفاده کنم. ضمنا اصولی مثل SOLID یادگیریش در یه زبان fully OOP شاید راحت تر از گولنگ باشه که بیشتر data oriented هست.

بازم تاکید میکنم این پیام اصلا تبلیغاتی نیست و نکاتی که اشاره کردم واقعا میتونه کاربردی باشه.


دم همه تون گرم 🌹

ان شاء الله خداوند عمر و سلامتی بده از هفته بعد جلسات GoCasts رو از سر میگیریم 💪

@gocasts

هر چقدر از خوبی این مقاله بگم، کم گفتم!
واقعیتش من اصلا در مورد Generics ذوق زده نشدم و همچنان تا وقتی که واقعا در کارم لازمش نداشته باشم سمتش نمیرم

این مقاله تکنیکال به زیبایی هر چه تمام تر نحوه پیاده سازی Generics در Go رو توضیح میده و کاملا شفاف توضیح میده که چرا در خیلی از موارد استفاده از Generics کد شما رو کندتر میکنه. برای من هم عجیبه که چرا در طراحی Generics اضافه شدن runtime overhead رو به کند شدن مرحله کامپایل ترجیح دادند. مقاله خیلی تکنیکاله ولی حتما مقدمه و موخره ش رو حداقل بخونید.

Generics can make your Go code slower
https://planetscale.com/blog/generics-can-make-your-go-code-slower

#generics #golang

@gocasts

سلام دوستان
اخیرا این بحث مطرح شده که توییتر قابلیت ویرایش رو اضافه کنه
این لینکی که گذاشم از طرف یکی از مهندسین سابق توییتر هست در مورد مشکلات مهندسی اضافه کردن قابلیت ادیت به سیستمی که بیش از یک دهه برای read در scale بالا بهینه شده
https://twitter.com/mjackson/status/1511790796135022598?s=19

در کتاب designing data intensive applications و احتمالا کلی جای دیگه هم میتونید از راه حل های استفاده شده در توییتر برای ساختن feed شخصی سازی شده از توییت ها برای هر کاربر بصورت اختصاصی آگاه بشید.
توییتر از ساختار hybrid استفاده میکنه (حداقل تا چند سال پیش). در این ساختار وقتی کاربری یک توییت رو منتشر میکنه، برای تک تک کاربرانی که کاربر مورد نظر رو follow می کنند، یک نسخه از توییت در message queue اختصاصی اون شخص قرار میگیره. اینطوری feed هر کاربر بصورت خودکار ساخته میشه و هر وقت کاربر بخواد feedش رو چک کنه توییتر لازم نیست هیچ کاری بکنه جز اینکه message های message queue اختصاصی اون شخص رو consume کنه.
اما این کار یه اشکالی داره، اشکالش اینه اگه کاربر منتشر کننده تعداد فالوئرهای زیادی داشته باشه مثلا ۲۰ میلیون کاربر، اونوقت توییتر مجبور میشه ۲۰ میلیون write در لحظه انتشار توییت انجام بده که خیلی عملیات سنگینیه. واسه همین از روش hybrid استفاده می‌کنه یعنی کاربرانی که فالوئر زیادی دارن توییت هاشونو در message queue وارد نمیکنه، بلکه اپلیکیشن کلاینت وقتی میخواد feed توییت رو لود کنه هم یه سری توییت از message queue میگیره و هم یه درخواست میزنه و لیست توییت های جدید کاربران پرمخاطبی که کاربر دنبال میکنه رو میگیره و این دو تارو ترکیب میکنه. اینطوری reaponse time خیلی معقول باقی میمونه چون تعداد فالوئرهای پرکاربر و توییت هاشون محدوده
حالا مشکلی که در این thread بهش اشاره کرده اینه که سیستمی که برای بیش از یک دهه روی read بهینه شده خیلی سخته بهش قابلیت edit اضافه کنن چون خیلی چیزارو بهم میریزه.

شما ایده ای ندارید؟

اصلاحیه:
با تشکر از امید جان حکایتی بابت تذکر
طبق این مقاله
http://highscalability.com/blog/2013/7/8/the-architecture-twitter-uses-to-deal-with-150m-active-users.html

البته مقاله قدیمی هست ولی چندین جاش تاکید کرده صرفا tweetid در سرویس تایملاین ذخیره میشه

Then it will start inserting the Tweet ID of the tweet into all those lists throughout the Redis cluster

What is being stored is the tweet ID of the generated tweet, the user ID of the originator of the tweet, and 4 bytes of bits used to mark if it’s a retweet or a reply or something else.

Since the timeline only contains tweet IDs they must “hydrate” those tweets

#software_design #twitter

@gocasts

سلام به همه دوستان خوبم
امیدوارم نوروز خوبی رو تا به اینجا سپری کرده باشید.

در مورد چالش معماری اول، من سعی کردم راه حل های پیشنهادی رو به صورت خلاصه در مقاله بررسی کنم و راه حل پیشنهادی خودم که transactional outbox بود رو شرح بدم. امیدوارم که مفید باشه، اینم لینک مقاله:
https://gocasts.ir/software-architecture-challenge-1?utm_source=telegram&utm_medium=message&utm_campaign=8

با تشکر از همه افرادی که در چالش مشارکت کردند، علی الخصوص افراد زیر که راه حل های پیشنهادی شون مطرح شد در مقاله، ببخشید اگه اسم شخصی جا افتاده

MarshalMan
koorosh_sa
mehdi_sadeghi_1996
OmidHekayati
Mohamadrezamomeni96
AmirHasanCE


#gocasts_challenge
#architecture

@gocasts

اصلاحیه: من در نیازمندی ها inconsistency نداشتن رو معیار قرار داده بودم، که امیدجان حکایتی به درستی اشاره کردند که باید مشخص بشه و از inconsistency نبودن، نمیشه لزوما برداشت eventual consistency داشت، حالا فارغ از اینکه بخوایم سر این موضوع بحث کنیم، تذکر ایشون بجاست و من باید رسما از عبارت eventual consistency استفاده میکردم نه inconsistency نداشتن
مرسی از شما
@OmidHekayati

سلام دوستان، امیدوارم حالتون خوب باشه
گاها پیش میاد دوستان عزیز در مورد مهندسی نرم افزار، گولنگ و حتی مسائل شغلی از بنده سوال میپرسند، من خیلی دوست دارم یه طوری باشه که بتونم جواب سوالات رو با شما به اشتراک بذارم، اینطوری هم یه مجموعه پرسش و پاسخ خوبی بعد از یک مدت شکل میگیره و هم دیگرانی که همون سوال تو ذهنشون بوده میتونن پاسخ بنده رو مطالعه کنن. (تضمینی در مورد درست بودن پاسخ نیست 😁)
حالا میخواستم از خودتون مشورت بگیرم که به چه صورت و در چه رسانه ای این کار رو بکنم.

همینجا تو کانال اصلی سوال و جواب هارو قرار بدم؟
یه کانال ثانویه مخصوص سوال و جواب ایجاد کنم؟
تو سایت GoCasts یه جایی مخصوص سوال و جواب ایجاد کنم؟
یه فروم مدرن به کمک Discourse بیارم بالا و اونجا تاپیک سوال و جواب داشته باشیم؟

اگه راه پیشنهادی دیگه ای دارید لطفا تو کامنت ها بگید

@gocasts

سلام دوستان
سال نو مبارک
عیدتون به شادی و سلامتی
ان شاء الله سال جدید و دهه جدید و قرن جدید مملو از اتفاقات خوب تو زندگیتون باشه
ان شاء الله که در کنار هم بتونیم یه سال خیلی خوب رو در GoCasts رقم بزنیم و همگی بتونیم سطح فنی خودمون رو ارتقا بدیم و به دوستان دیگه مون هم کمک کنیم در کارشون موفق باشن. امیدوارم سالی باشه که بتونیم کلی محصول خوب نرم افزاری تولید کنیم و حال کلی کاربر رو خوب کنیم.

به یاری خدا امسال کلی برنامه جذاب فنی خواهیم داشت که با هم پیش میبریم 😍💪

دمتون گرم که همراهی می کنید 🌹

یا علی

@gocasts

عیدی نیمه شعبان GoCasts به عزیزان اول راهی 🌹

نیمه شعبان، ولادت امام زمان عجل الله تعالی فرجه الشریف مبارک

یا ابا صالح المهدی ادرکنی ❤️

اگر یک نفر را به او وصل کردی
برای سپاهش تو سردار یاری

عیدتون مبارک، به مناسبت این روز مبارک، عزیزانی که در ابتدای راه هستند و فکر میکنن به راهنما و همراه نیاز دارن برای ادامه راه و‌ ورود به بازار کار، بنده در حد توان در خدمتشون هستم ان شاء الله.
به لطف خدا و بسته به سطح فنی خودتون و وقتی که دارید و همتی که دارید، بین ۳ ماه تا نهایتا ۹ ماه میتونید وارد بازار کار بشید، اگه تمایل داشتید لطفا به این آی دی پیام بدید، قدمتون روی چشم.
@lifography

من الحمدلله قبلا تجربه این کار رو داشتم و عزیزانی که سعادت داشتم در خدمتشون باشم بعضا مهاجرت کردن آلمان یا در اسنپ مشغول به کار هستند، الان هم در کانال عضو هستند (خیلی مخلصیم 😉❤️). همه اعتبار این کار هم به خودشون برمیگرده، بنده فقط سعی کردم مسیر رو شفاف تر و آسان تر کنم، اگه تونسته باشم!

دمتون گرم

یا علی 🌹❤️

@gocasts

شما به پروانه ها چی عیدی میدی؟

مهم ترین رسالت GoCasts در قالب مسئولیت اجتماعی انتقال دادن «حس خوب» هست. وظیفه اجتماعی ما در GoCasts ایجاب میکنه همیشه از تخصص مون در راستایی استفاده کنیم که به ما این قدرت رو بده حال خوب رو به دیگران انتقال بدیم.

کوچیکترین عیدی شما میتونه منتشر کردن این مقاله در رسانه های خودتون باشه

اما من یقین داریم شما عیدی های خیلی خیلی بزرگتری رو میتونید به پروانه ها هدیه بدید، برای جزییات بیشتر، لطفا مقاله زیر رو بخونید
https://gocasts.ir/social-responsibility-home-of-butterflies-piece-of-heaven-on-earth?utm_source=telegram&utm_medium=message&utm_campaign=7

این پست بی ارتباط به چالش معماری شماره یک نیست، ان شاءالله در سال ۱۴۰۱ به کمک برخی از دوستان خوب GoCasts تلاش می کنیم بهترین نرم افزاری که تو عمرمون می تونستیم بسازیم رو بسازیم و تقدیم به پروانه های نازنین کنیم. شاید تونستیم بخشی از پروژه رو هم open source کنیم، که همه جوره از نتیجه تلاشمون به دیگران «حس خوب» منتقل کرده باشیم.

#social_responsibility

@gocasts

سلام صبح بخیر
با تشکر از مشارکت همه عزیزان، برای شفافیت بیشتر به شرح موضوع چند آیتم اضافه شد که مساله روشن تر بشه برای دوستان

چالش معماری - شماره ۱

سلام خدمت همه دوستان، یه سناریو با نیازمندی هاشو تعریف می کنم، لطفا بهش فکر کنید، راه حلی که به ذهنتون میرسه رو ارائه بدید.

مقدمه
- سرویس core در هاستی در آلمان قرار داره (laravel) شامل دیتابیس حاوی جداول user و payment
- سرویس اختصاصی مشتریان بصورت جداگانه در سروری در ایران قراره توسعه داده بشه با golang
- سرویس مشتریان احتیاج داره دیتای user و payment رو داشته باشه
- سرویس core رو نمیتونیم از هاست آلمان خارج کنیم، چون بشدت مهمه که اونجا downtime پایینی داره
- سرویس مشتریان چون گولنگیه طبیعتا نمیشه روی همون هاست باشه و مجبور هستیم distributed بهش نگاه کنیم
- دوست داریم سرویس core رو بیاریم روی گولنگ ولی فعلا نمیشه این اتفاق بیفته پس فراموشش کنید
- اهمیت سرویس core خیلی بیشتره نباید down بودن سرویس مشتریان باعث بشه درخواست به core هم fail بشه
- دقت کنید core روی هاست هست و دیتابیس کنارشه، محدودیت زیادی روی هاست داریم
- دیتای payment رو immutable در نظر بگیرید ولی دیتای user میتونه آپدیت بشه

این مقدمه رو گفتم که هم بدونید چالش واقعیه، هم الکی دوست نداریم پیچیدگی به سیستم اضافه کنیم اما در لحظه ناچار هستیم distributed نگاه کنیم به سرویس هامون.

خب حالا نیازمندی چیه؟
- میخوایم دیتای core رو sync کنیم روی دیتابیس مشتریان (یکطرفه)

معیار نرم افزاری مهم مون چیه؟
- به هیچ وجه inconsistency نداشته باشه دیتامون
- کمترین میزان ارسال دیتا رو داشته باشیم (مجبور نباشیم هربار همه چیز رو ارسال کنیم یا رکوردهای redundant الکی ارسال کنیم مجدد)
- سرعت sync شدن دیتا بالا باشه

هر راه حلی که به ذهنتون میرسه یا قبلا تجربه ش رو داشتید لطفا در کامنت ارائه بدید. لطفا در ارائه جواب سعی کنید در یک پیام کامل با ذکر دلایل جواب رو ارائه بدید و از ارسال جواب های کوتاه کوتاه خودداری کنید.

راه حل های خوب با ذکر دلیل به عنوان جواب تو کانال ارائه میشه که هم کلی چیز یاد بگیریم، هم ان شاءالله نتیجه پیاده سازی و performanceش بهتون اعلام میشه. سعی میکنیم کد سرویس ش رو هم اگه بشه open source کنیم ان شاءالله

نکته آخر: من جواب تو ذهنم دارم، دنبال جواب بهترم، ضمنا این پروژه واقعیه اما عایده مالی برای بنده نداره

لطفا تا دو سه روز آینده جواب هاتونو ارائه بدید و بعد من راه حل های خوب رو تو کانال قرار میدم.

#gocasts_challenge #architecture

@gocasts