A Crash Course in API Versioning Strategies (1) (1).pdf
3.4 MB
#bytebytego #tips #pro_guide
A Crash Course in API Versioning Strategies
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
A Crash Course in API Versioning Strategies
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
👍2🔥2🍾1
The Top 3 Resume Mistakes Costing You the Job.pdf
5 MB
#bytebytego #tips #pro_guide
The Top 3 Resume Mistakes Costing You the Job
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
The Top 3 Resume Mistakes Costing You the Job
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
👍3🍾2
How do We Design for High Availability_.pdf
1.7 MB
#bytebytego #tips #pro_guide
How do We Design for High Availability?
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
How do We Design for High Availability?
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
👍2🔥2🕊2❤1
Software Engineer - Developer Experience
Role Qualifications and Requirements:
You have 3+ years of validated experience as a Software Developer. You have worked on the design, development, testing, and monitoring of distributed systems and product(s) that impact millions of customers
You are already proficient in at least one of the following programming languages: Golang, Python, Java, Perl. More importantly, you are eager to learn what is required to develop and support both new and existing solutions
You’re experienced in developing CI/CD infrastructure and Infrastructure as Code (terraform), preferably for multiple teams with varying demands, and have a deep understanding of Git
You are an excellent communicator and able to influence and cooperate with people at all levels
https://jaabz.com/jobs/4109-software-engineer-developer-experience
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
Role Qualifications and Requirements:
You have 3+ years of validated experience as a Software Developer. You have worked on the design, development, testing, and monitoring of distributed systems and product(s) that impact millions of customers
You are already proficient in at least one of the following programming languages: Golang, Python, Java, Perl. More importantly, you are eager to learn what is required to develop and support both new and existing solutions
You’re experienced in developing CI/CD infrastructure and Infrastructure as Code (terraform), preferably for multiple teams with varying demands, and have a deep understanding of Git
You are an excellent communicator and able to influence and cooperate with people at all levels
https://jaabz.com/jobs/4109-software-engineer-developer-experience
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
🎉4👍1
یکی از سوال های محبوب مصاحبه بک اند: فرق Kafka و RabbitMQ چیه؟
۱. Performance and Scalability
کافکا برای throughput بالا و horizontal scalability ساخته شده است. هرچند RabbitMQ پرفرمنس بالایی دارد وقتی throughput و حجم داده زیاد باشد کافکا مناسب تر است.
۲. Message Ordering
در RabbitMQ در یک صف ترتیب پیام ها حفظ میشود. در کافکا در یک پارتیشن ترتیب پیام های یک topic حفظ میشود اما نه در پارتیشن های مختلف.
۳. Message Priority
در RabbitMQ از اولویت پیام ها پشتیبانی میشود که اجازه میدهد پیام های با اولویت بالا زودتر پردازش شوند. کافگا به صورت built-in از اولویت پشتیبانی نمیکند.
۴. Message Model
مدل پیام های RabbitMQ مبتنی بر صف است و از پروتکل AMQP تبعیت میکند اما کافکا مدل لاگ توزیع شده دارد.
۵. Durability:
برای اینکه پیام ها Durable باشند یعنی اگر failure رخ دهد از بین نروند، در RabbitMQ نیاز به تنظیمات است اما کافکا به طور درونی از این مورد پشتیبانی میکند.
۶. Message Routing
در Rabbit برای مسیریابی پیام ها پیشرفته تر و با استفاده از exchange و binding انجام میشود اما در کافکا ابتدایی تر و با استفاده از topic و پارتیشن ها انجام میشود.
۷. Replication
در Rabbit برای replication می توان از Mirrored Queue استفاده کرد. و کافکا نیز به صورت درونی از partition replication پشتیبانی میکند.
8. Stream Processing
هر دو کافکا و Rabbit از پردازش Stream پشتیبانی می کنند.
9. Latency
طراحی RabbitMQ برای تاخیر کم است و در جایی که نیاز به پردازش نزدیک به realtime است، استفاده میشود.
10. License
لایسنس Rabbit از نوع Mozilla Public License و لایسنس کافکا از نوع 2.0 Apache است.
RabbitMQ یک message broker اما کافکا یک distributed streaming platform است.
یک فرق اساسی این است که کافکا pull-based اما RabbitMQ داری پروتکل push-based است.
یک سیستم pull-based صبر می کند تا مصرف کننده ها داده را درخواست کنند.
یک سیستم push-based به صورت اتوماتیک پیام ها را به مصرف کنندهای که subscribe کردهاند میفرستد.
یک سیستم pull-based برای کافکا معنی میدهد. چون در کافکا پیام های هر پارتیشن ترتیب دارد و کاربران می توانند با throughput بیشتری داده ها را دریافت کنند.
RabbitMQ یک push model با محدودیت prefetch دارد. برای پیام هایی با low-latency مناسب است. هدف اصلی مدل push این است که پیام ها هر چه سریعتر توزیع شوند اما یکی یکی.
RabbitMQ می تواند هر ثانیه 4k تا 10k پیام هر ثانیه بفرستد اما کافکا می تواند ۱ میلیون پیام هر ثانیه بفرستد.
در Rabbit مدل smart broker و dumb consumer استفاده میشود اما در کافکا مدل dumb broker و smart consumer استفاده میشود.
نگه داری پیام در RabbitMQ به صورت acknownledge-based اما در کافکا به صورت policy-based است.
در RabbitMQ هیچ محدودیتی برای سایز payload نیست اما در کافکا به صورت پیش فرض یک مگابایت است.
تمرین عملی: یک اپلیکیشن چت بنویسید که چند نمونه از بک اند بالا باشد و هر کلاینت به یک بک اند وصل شود و از طریق کافکا یا RabbitMQ بک اند ها رو با هم sync کنید.
#DevTwitter | <Pouria Jahandideh/>
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
۱. Performance and Scalability
کافکا برای throughput بالا و horizontal scalability ساخته شده است. هرچند RabbitMQ پرفرمنس بالایی دارد وقتی throughput و حجم داده زیاد باشد کافکا مناسب تر است.
۲. Message Ordering
در RabbitMQ در یک صف ترتیب پیام ها حفظ میشود. در کافکا در یک پارتیشن ترتیب پیام های یک topic حفظ میشود اما نه در پارتیشن های مختلف.
۳. Message Priority
در RabbitMQ از اولویت پیام ها پشتیبانی میشود که اجازه میدهد پیام های با اولویت بالا زودتر پردازش شوند. کافگا به صورت built-in از اولویت پشتیبانی نمیکند.
۴. Message Model
مدل پیام های RabbitMQ مبتنی بر صف است و از پروتکل AMQP تبعیت میکند اما کافکا مدل لاگ توزیع شده دارد.
۵. Durability:
برای اینکه پیام ها Durable باشند یعنی اگر failure رخ دهد از بین نروند، در RabbitMQ نیاز به تنظیمات است اما کافکا به طور درونی از این مورد پشتیبانی میکند.
۶. Message Routing
در Rabbit برای مسیریابی پیام ها پیشرفته تر و با استفاده از exchange و binding انجام میشود اما در کافکا ابتدایی تر و با استفاده از topic و پارتیشن ها انجام میشود.
۷. Replication
در Rabbit برای replication می توان از Mirrored Queue استفاده کرد. و کافکا نیز به صورت درونی از partition replication پشتیبانی میکند.
8. Stream Processing
هر دو کافکا و Rabbit از پردازش Stream پشتیبانی می کنند.
9. Latency
طراحی RabbitMQ برای تاخیر کم است و در جایی که نیاز به پردازش نزدیک به realtime است، استفاده میشود.
10. License
لایسنس Rabbit از نوع Mozilla Public License و لایسنس کافکا از نوع 2.0 Apache است.
RabbitMQ یک message broker اما کافکا یک distributed streaming platform است.
یک فرق اساسی این است که کافکا pull-based اما RabbitMQ داری پروتکل push-based است.
یک سیستم pull-based صبر می کند تا مصرف کننده ها داده را درخواست کنند.
یک سیستم push-based به صورت اتوماتیک پیام ها را به مصرف کنندهای که subscribe کردهاند میفرستد.
یک سیستم pull-based برای کافکا معنی میدهد. چون در کافکا پیام های هر پارتیشن ترتیب دارد و کاربران می توانند با throughput بیشتری داده ها را دریافت کنند.
RabbitMQ یک push model با محدودیت prefetch دارد. برای پیام هایی با low-latency مناسب است. هدف اصلی مدل push این است که پیام ها هر چه سریعتر توزیع شوند اما یکی یکی.
RabbitMQ می تواند هر ثانیه 4k تا 10k پیام هر ثانیه بفرستد اما کافکا می تواند ۱ میلیون پیام هر ثانیه بفرستد.
در Rabbit مدل smart broker و dumb consumer استفاده میشود اما در کافکا مدل dumb broker و smart consumer استفاده میشود.
نگه داری پیام در RabbitMQ به صورت acknownledge-based اما در کافکا به صورت policy-based است.
در RabbitMQ هیچ محدودیتی برای سایز payload نیست اما در کافکا به صورت پیش فرض یک مگابایت است.
تمرین عملی: یک اپلیکیشن چت بنویسید که چند نمونه از بک اند بالا باشد و هر کلاینت به یک بک اند وصل شود و از طریق کافکا یا RabbitMQ بک اند ها رو با هم sync کنید.
#DevTwitter | <Pouria Jahandideh/>
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
👍13❤1 1
Netflix_ What Happens When You Press Play_.pdf
3.8 MB
#bytebytego #tips #pro_guide
Netflix: What Happens When You Press Play?
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
Netflix: What Happens When You Press Play?
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
🔥7 2
💬 پاول دورف موسس #تلگرام تو مصاحبه اخیرش گفته که:
✅ کدنویسی تلگرام رو برادرش انجام داده و خودش هم مدیر محصول تلگرام هس.
✅ هر امکاناتی که به تلگرام اضافه میشه، ایده شخص خودشه.
✅ صد درصد مالکیت کمپانی هم به خودش تعلق داره.
✅ کمپانی تلگرام واحد منابع انسانی و جذب نیرو نداره و کلا ۳۰ تا مهندس داره و برنامهنویسهاشو از بین مسابقاتی که برگذار میکنه انتخاب میکنه.
💙 میگه ما بهترینِ بهترینِ بهترینهارو انتخاب میکنیم.
❗️خیلی جالبه ۹۰۰ میلیون کاربر توسط ۳۰ نفر مدیریت میشه👌🏻
🔹پاول دورف با ۱۵.۵ میلیارد دلار ثروت میگه که هیچ کدوم از چیزهایی که بقیه پولدارها مثل هواپیما و کشتی و حتی خونه دارن رو من ندارم (مستأجر هست).
🔹فلسفش اینه که هرگونه دارایی، باعث میشه که سرم به اونا گرم بشه و وقتم رو بگیره و منو از هدفم دور کنه.
🔹میگه ترجیح میدم تمام وقتم رو بذارم برای بستری که به میلیونها نفر اجازه میده باهم در ارتباط باشن، تا اینکه دغدم رو بذارم برای دیزاین خونهام، جایی که فقط خودم و اطرافیانم میتونیم ازش استفاده کنیم.
🔹میگه اولویت اول تلگرام از همون ابتدا حفظ امنیت کاربرانش بوده و برای همین همیشه از سمت دولتهای مختلف تحت فشار قرار گرفته که اطلاعات کاربران رو بده.
🔹مجبور شده از کشورش روسیه بزنه بیرون و در آمریکا هم میخواستن بکشنش. در اروپا هم بهش اجازه کار و جذب نیرو نمیدادن. ۷ ساله تو اماراته و تنها دولتی بوده که اذیتش نکرده.
🔹میگه من به آزادی بیان اعتقاد دارم و درخواست دولتهارو رد میکنم. تنها فشار اساسی از طرف اپل و گوگل بوده که خیلی جاها باید بهش تن بده تا تلگرام از اپاستور و گوگلپلی حذف نشه.
🔹تلگرام با ۹۰۰ میلیون کاربر تا حالا یکبار هم برای جذب کاربر تبلیغات انجام نداده.
🔹ازش پرسید که چطوری تونستی بدون تبلیغات به چنین چیزی برسی؟ میگه چون آدمها باهوشن. محصول خوب که میبینن، سرعت و امنیت و امکاناتش رو که از نزدیک لمس میکنن دیگه بیخیالش نمیشن و تازه به هم معرفیش هم میکنن.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
✅ کدنویسی تلگرام رو برادرش انجام داده و خودش هم مدیر محصول تلگرام هس.
✅ هر امکاناتی که به تلگرام اضافه میشه، ایده شخص خودشه.
✅ صد درصد مالکیت کمپانی هم به خودش تعلق داره.
✅ کمپانی تلگرام واحد منابع انسانی و جذب نیرو نداره و کلا ۳۰ تا مهندس داره و برنامهنویسهاشو از بین مسابقاتی که برگذار میکنه انتخاب میکنه.
💙 میگه ما بهترینِ بهترینِ بهترینهارو انتخاب میکنیم.
❗️خیلی جالبه ۹۰۰ میلیون کاربر توسط ۳۰ نفر مدیریت میشه👌🏻
🔹پاول دورف با ۱۵.۵ میلیارد دلار ثروت میگه که هیچ کدوم از چیزهایی که بقیه پولدارها مثل هواپیما و کشتی و حتی خونه دارن رو من ندارم (مستأجر هست).
🔹فلسفش اینه که هرگونه دارایی، باعث میشه که سرم به اونا گرم بشه و وقتم رو بگیره و منو از هدفم دور کنه.
🔹میگه ترجیح میدم تمام وقتم رو بذارم برای بستری که به میلیونها نفر اجازه میده باهم در ارتباط باشن، تا اینکه دغدم رو بذارم برای دیزاین خونهام، جایی که فقط خودم و اطرافیانم میتونیم ازش استفاده کنیم.
🔹میگه اولویت اول تلگرام از همون ابتدا حفظ امنیت کاربرانش بوده و برای همین همیشه از سمت دولتهای مختلف تحت فشار قرار گرفته که اطلاعات کاربران رو بده.
🔹مجبور شده از کشورش روسیه بزنه بیرون و در آمریکا هم میخواستن بکشنش. در اروپا هم بهش اجازه کار و جذب نیرو نمیدادن. ۷ ساله تو اماراته و تنها دولتی بوده که اذیتش نکرده.
🔹میگه من به آزادی بیان اعتقاد دارم و درخواست دولتهارو رد میکنم. تنها فشار اساسی از طرف اپل و گوگل بوده که خیلی جاها باید بهش تن بده تا تلگرام از اپاستور و گوگلپلی حذف نشه.
🔹تلگرام با ۹۰۰ میلیون کاربر تا حالا یکبار هم برای جذب کاربر تبلیغات انجام نداده.
🔹ازش پرسید که چطوری تونستی بدون تبلیغات به چنین چیزی برسی؟ میگه چون آدمها باهوشن. محصول خوب که میبینن، سرعت و امنیت و امکاناتش رو که از نزدیک لمس میکنن دیگه بیخیالش نمیشن و تازه به هم معرفیش هم میکنن.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
Factors to Consider in Database Selection - by Alex Xu.pdf
4.4 MB
#bytebytego #tips #pro_guide
Factors to Consider in Database Selection
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
Factors to Consider in Database Selection
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
From 0 to Millions_ A Guide to Scaling Your App - Part 3.pdf
2.1 MB
#bytebytego #tips #pro_guide
From 0 to Millions A Guide to Scaling Your App
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
From 0 to Millions A Guide to Scaling Your App
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
How Discord Serves 15-Million Users on One Server.pdf
3.7 MB
#bytebytego #tips #pro_guide
How Discord Serves 15-Million Users on One Server
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
How Discord Serves 15-Million Users on One Server
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
سوال مصاحبه: مزایای استفاده از BFF را بیان کنید.
۱. Diverse Frontend Needs: یک اپلیکیشن موبایل، یک برنامه وب، و یک تلویزیون هوشمند نیازمندی های متفاوتی دارند.
۲. Performance Optimization: دستگاه های موبایل ممکن است در شبکه های کندتری باشند و قدرت پردازش کمتری داشته باشند. BFF به ما اجازه میدهد که داده را برای هر دستگاه بهینه کنیم و برنامه responsive باشد.
۳. Simplified Frontend Logic: با BFF فرانت اند ها نیاز ندارند که با مایکروسرویس های مختلف صحبت کنند بلکه یک بک اندی دارند که داده ها را برایشان aggregate و پردازش می کند.
۴. Enhanced User Experience: با در نظر گرفتن نیاز و توانایی های هر دستگاه BFF مطمئن میشود که هر کاربر بهترین تجربه را صرف نظر از دستگاهش دارد.
۵. Easier Maintenance and Upgrades: چون هر بک اند فرانت اند خاص خودش را دارد انجام تغییرات ساده تر میشود. می توانیم بک اند موبایل را آپدیت کنیم بدون اینکه بک اند وب را تغییر دهیم.
۶. Security: به ما امکان میدهد که برای هر کلاینت الزامات امنیتی خاص خودش را داشته باشیم. مثلا ممکن است authentication در اپ mobile با وب فرق کند.
۷. Agility: تیم ها می توانند به طور مستقل روی BFF خود کار کنند، و پروسه توسعه سریعتر شود.
۸. Scalability: چون هر فرانت اند، بک اند خودش را دارد، راحت تر میتوان قسمت هایی از سیستم را مستقل از بقیه قسمت ها Scale کرد.
۹. Consistency: می تواند به ارائه یک API سازگار کمک کند. وقتی مایکروسرویس های مختلف تغییر میکنند ما یک لایه stable در جلو آنها داریم که consistent است.
۱۰. Version Control: اپلیکیشن های فرانت قدیمی ممکن است به ورژن های قدیمی تر بک اند نیاز داشته باشند. BFF این امکان را به ما میدهد که هر فرانت اند ورژن مورد نیاز بک اند خود را دریافت کند.
۱۱. Cross Functional Teams: این الگو به ما کمک میکند تا تیم هایی داشته باشیم که قابلیت های end-to-end توسعه دهند. یعنی وقتی یک functionality نیاز است از فرانت تا بک اند آن را یک تیم خاص توسعه دهد که همکاری و سرعت تحویل بالا میرود.
۱۲. Facilitates A/B Testing: به AB تستینگ کمک می کند. چون میتوانیم یک فیچر جدید را در یک فرانت اند خاص تست کنیم بدون اینکه سایر بک اند ها را تغییر دهیم.
۱۳. Localization and Internationalization: ممکن است برای مناطق مختلف فرانت اند های مختلفی داشته باشیم در این صورت میتوانیم بک اند را خاص فیچر های آن منطقه سفارشی کنیم.
۱۴. Handling Legacy Systems: در حین گذر از مونولیت به مایکروسرویس BFF مانند پلی بین فرانت اند های جدید برای تعامل با سیستم های legacy عمل میکند.
۱۵. Reduces Bandwidth Usage: اگر فقط داده هایی که برای دستگاه موبایل نیاز است را به آن بفرستیم پهنای باند کمتری مصرف میشود.
۱۶. Error Handling and Resilience: وقتی خطایی وجود دارد ممکن است بخواهیم در Web app و موبایل به نحو متفاوتی آن را مدیریت کنیم.
17. Feature Flagging: می توانیم یه سری فیچر ها را فقط در یک سری از فرانت اند ها داشته باشیم.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
۱. Diverse Frontend Needs: یک اپلیکیشن موبایل، یک برنامه وب، و یک تلویزیون هوشمند نیازمندی های متفاوتی دارند.
۲. Performance Optimization: دستگاه های موبایل ممکن است در شبکه های کندتری باشند و قدرت پردازش کمتری داشته باشند. BFF به ما اجازه میدهد که داده را برای هر دستگاه بهینه کنیم و برنامه responsive باشد.
۳. Simplified Frontend Logic: با BFF فرانت اند ها نیاز ندارند که با مایکروسرویس های مختلف صحبت کنند بلکه یک بک اندی دارند که داده ها را برایشان aggregate و پردازش می کند.
۴. Enhanced User Experience: با در نظر گرفتن نیاز و توانایی های هر دستگاه BFF مطمئن میشود که هر کاربر بهترین تجربه را صرف نظر از دستگاهش دارد.
۵. Easier Maintenance and Upgrades: چون هر بک اند فرانت اند خاص خودش را دارد انجام تغییرات ساده تر میشود. می توانیم بک اند موبایل را آپدیت کنیم بدون اینکه بک اند وب را تغییر دهیم.
۶. Security: به ما امکان میدهد که برای هر کلاینت الزامات امنیتی خاص خودش را داشته باشیم. مثلا ممکن است authentication در اپ mobile با وب فرق کند.
۷. Agility: تیم ها می توانند به طور مستقل روی BFF خود کار کنند، و پروسه توسعه سریعتر شود.
۸. Scalability: چون هر فرانت اند، بک اند خودش را دارد، راحت تر میتوان قسمت هایی از سیستم را مستقل از بقیه قسمت ها Scale کرد.
۹. Consistency: می تواند به ارائه یک API سازگار کمک کند. وقتی مایکروسرویس های مختلف تغییر میکنند ما یک لایه stable در جلو آنها داریم که consistent است.
۱۰. Version Control: اپلیکیشن های فرانت قدیمی ممکن است به ورژن های قدیمی تر بک اند نیاز داشته باشند. BFF این امکان را به ما میدهد که هر فرانت اند ورژن مورد نیاز بک اند خود را دریافت کند.
۱۱. Cross Functional Teams: این الگو به ما کمک میکند تا تیم هایی داشته باشیم که قابلیت های end-to-end توسعه دهند. یعنی وقتی یک functionality نیاز است از فرانت تا بک اند آن را یک تیم خاص توسعه دهد که همکاری و سرعت تحویل بالا میرود.
۱۲. Facilitates A/B Testing: به AB تستینگ کمک می کند. چون میتوانیم یک فیچر جدید را در یک فرانت اند خاص تست کنیم بدون اینکه سایر بک اند ها را تغییر دهیم.
۱۳. Localization and Internationalization: ممکن است برای مناطق مختلف فرانت اند های مختلفی داشته باشیم در این صورت میتوانیم بک اند را خاص فیچر های آن منطقه سفارشی کنیم.
۱۴. Handling Legacy Systems: در حین گذر از مونولیت به مایکروسرویس BFF مانند پلی بین فرانت اند های جدید برای تعامل با سیستم های legacy عمل میکند.
۱۵. Reduces Bandwidth Usage: اگر فقط داده هایی که برای دستگاه موبایل نیاز است را به آن بفرستیم پهنای باند کمتری مصرف میشود.
۱۶. Error Handling and Resilience: وقتی خطایی وجود دارد ممکن است بخواهیم در Web app و موبایل به نحو متفاوتی آن را مدیریت کنیم.
17. Feature Flagging: می توانیم یه سری فیچر ها را فقط در یک سری از فرانت اند ها داشته باشیم.
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
How do We Design for High Availability_.pdf
2 MB
#bytebytego #tips #pro_guide
How do We Design for High Availability
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
How do We Design for High Availability
➖➖➖➖➖➖➖➖
🕊 @gopher_academy | @GolangEngineers
❤2🎉1🍾1