Web Analytics

system-design-primer

⭐ 318813 stars Assamese by donnemartin

English ∙ 日本語 ∙ 简体中文 ∙ 繁體中文 | العَرَبِيَّة‎ ∙ বাংলা ∙ Português do Brasil ∙ Deutsch ∙ ελληνικά ∙ עברית ∙ Italiano ∙ 한국어 ∙ فارسی ∙ Polski ∙ русский язык ∙ Español ∙ ภาษาไทย ∙ Türkçe ∙ tiếng Việt ∙ Français | Add Translation

এই গাইডটো অনুবাদ কৰক!

ছিষ্টেম ডিজাইন প্ৰাইমাৰ


প্ৰেৰণা

বৃহৎ পৰিসৰৰ ছিষ্টেম ডিজাইন কৰিবলৈ শিকক।
>
ছিষ্টেম ডিজাইন সাক্ষাৎকাৰৰ বাবে প্ৰস্তুতি লওক।

বৃহৎ পৰিসৰৰ ছিষ্টেম ডিজাইন কৰিবলৈ শিকক

স্কেলেবেল ছিষ্টেম ডিজাইন কৰিবলৈ শিকিলে আপোনাক এটি ভাল ইঞ্জিনিয়াৰ হ'বলৈ সহায় কৰিব।

ছিষ্টেম ডিজাইন এটা বিস্তৃত বিষয়। ছিষ্টেম ডিজাইন নীতিসমূহৰ ওপৰত অসংখ্য উৎস ৱেবত ছৰিয়াই থকা আছে।

এই ৰেপ'টো হৈছে সংগঠিত সংকলন যি আপোনাক স্কেলত ছিষ্টেম নিৰ্মাণ কৰিবলৈ শিকাত সহায় কৰে।

মুক্ত উৎস সমুদায়ৰ পৰা শিকক

এইটো সদায় নবীকৃত হোৱা মুক্ত উৎস প্ৰকল্প।

অংশগ্ৰহণ স্বাগতম!

ছিষ্টেম ডিজাইন সাক্ষাৎকাৰৰ বাবে প্ৰস্তুতি লওক

কোডিং সাক্ষাৎকাৰৰ উপৰিও, ছিষ্টেম ডিজাইন হৈছে প্ৰযুক্তিগত সাক্ষাৎকাৰ প্ৰক্ৰিয়াৰ এটা আৱশ্যকীয় অংশ বহু টেক কোম্পানীত।

সাধাৰণ ছিষ্টেম ডিজাইন সাক্ষাৎকাৰ প্ৰশ্ন অনুশীলন কৰক আৰু আপোনাৰ উত্তৰসমূহ নমুনা সমাধানৰ সৈতে তুলনা কৰক: আলোচনা, কোড, আৰু চিত্ৰ।

সাক্ষাৎকাৰ প্ৰস্তুতিৰ বাবে অতিৰিক্ত বিষয়সমূহ:

Anki ফ্লেশকাৰ্ডছ


দান কৰা Anki ফ্লেশকাৰ্ড ডেকসমূহ-এ spaced repetition ব্যৱহাৰ কৰি মুখ্য চিষ্টেম ডিজাইন ধাৰণাসমূহ মনত ৰাখিবলৈ সহায় কৰে।

ভ্ৰমনকালত ব্যৱহাৰৰ বাবে উৎকৃষ্ট।

কোডিং ৰিসৰ্চ: ইন্টাৰেক্টিভ কোডিং চেলেঞ্জসমূহ

কোডিং ইন্টাৰভিউ-ৰ বাবে প্রস্তুতিৰ বাবে ৰিসৰ্চ বিচাৰি আছেনে?


ভগ্নি ৰেপো ইন্টাৰেক্টিভ কোডিং চেলেঞ্জসমূহ চাওক, য'ত এটা অতিৰিক্ত Anki ডেক আছে:

অৱদান আগবঢ়োৱা

সমাজৰ পৰা শিকক।

সহায় কৰিবলৈ pull request জমা দিয়াৰ বাবে স্বতন্ত্ৰ অনুভৱ কৰক:

পলিছিংৰ প্ৰয়োজন থকা সমল উন্নয়নাধীন হিচাপে সংৰক্ষিত হৈছে।

অংগ্ৰহণৰ নিয়মাৱলী পৰ্যালোচনা কৰক।

চিষ্টেম ডিজাইন বিষয়বস্তুৰ সূচী

বিভিন্ন চিষ্টেম ডিজাইন বিষয়বস্তুৰ সংক্ষিপ্তসাৰ, লাভ আৰু ক্ষতি সহ। প্ৰত্যেকটো এটা সমঝোতা।
>
প্ৰত্যেক অংশত অধিক গভীৰ উৎসৰ লিংক থাকে।


অধ্যয়ন গাইড

আপোনাৰ সাক্ষাৎকাৰৰ সময়সূচী (সৰু, মধ্যম, দীঘল) অনুসৰি পৰ্যালোচনাৰ বাবে পৰামৰ্শিত বিষয়সমূহ।

Imgur

প্ৰঃ: সাক্ষাৎকাৰৰ বাবে, মই ইয়াত সকলো জানিব লাগেনে?

উঃ: নহয়, সাক্ষাৎকাৰৰ বাবে প্ৰস্তুতিৰ বাবে আপোনাৰ ইয়াত সকলো জানিব নালাগে।

সাক্ষাৎকাৰত আপোনাক কি সোধা হ'ব তাৰ ওপৰত নিৰ্ভৰ কৰে এনেধৰণৰ পৰিৱৰ্তনশীলতাত:

অধিক অভিজ্ঞ প্ৰাৰ্থীৰ পৰা সাধাৰণতে ছিষ্টেম ডিজাইন সম্পৰ্কে অধিক জ্ঞান আশা কৰা হয়। স্থপতি বা দলৰ নেতাসকলৰ পৰা একক অৱদানকাৰীৰ তুলনাত অধিক আশা কৰা হয়। শীৰ্ষ প্ৰযুক্তি কোম্পানিসমূহত সাধাৰণতে এটা বা ততোধিক ডিজাইন সাক্ষাৎকাৰ পৰ্যায় থাকে।

ব্যাপকভাৱে আৰম্ভ কৰক আৰু কিছুমান ক্ষেত্ৰত গভীৰভাৱে যাওক। বিভিন্ন মুখ্য চিষ্টেম ডিজাইন বিষয়সমূহৰ বিষয়ে অলপ জানিবলৈ সহায় কৰে। তলত দিয়া গাইডটো আপোনাৰ সময়সীমা, অভিজ্ঞতা, যি পদৰ বাবে সাক্ষাৎকাৰ দিব, আৰু যি কোম্পানিত সাক্ষাৎকাৰ দিব, তাৰ ভিত্তিত সমন্বয় কৰক।

| | চুটি | মধ্যম | দীঘল | |---|---|---|---| | চিষ্টেম ডিজাইন বিষয়সমূহ পঢ়ি চিষ্টেমবোৰ কেনেকৈ কাম কৰে তাৰ ব্যাপক বুজ লওক | :+1: | :+1: | :+1: | | যি কোম্পানিত সাক্ষাৎকাৰ দিব, সেইবোৰৰ কোম্পানী ইঞ্জিনীয়াৰিং ব্লগৰ কিছুমান প্ৰবন্ধ পঢ়ক | :+1: | :+1: | :+1: | | বাস্তৱিক স্থাপত্যসমূহৰ কিছুমান পঢ়ক | :+1: | :+1: | :+1: | | চিষ্টেম ডিজাইন সাক্ষাৎকাৰ প্ৰশ্নৰ প্ৰৱেশ পোনপটীয়া কৰক | :+1: | :+1: | :+1: | | সমাধানসহ চিষ্টেম ডিজাইন সাক্ষাৎকাৰ প্ৰশ্ন অনুশীলন কৰক | কিছুমান | বহুত | বেছিভাগ | | সমাধানসহ অবজেক্ট-অৰিয়েন্টেড ডিজাইন সাক্ষাৎকাৰ প্ৰশ্ন অনুশীলন কৰক | কিছুমান | বহুত | বেছিভাগ | | অতিৰিক্ত চিষ্টেম ডিজাইন সাক্ষাৎকাৰ প্ৰশ্ন পোনপটীয়া কৰক | কিছুমান | বহুত | বেছিভাগ |

চিষ্টেম ডিজাইন সাক্ষাৎকাৰ প্ৰশ্নৰ প্ৰৱেশ কেনেকৈ কৰিব

চিষ্টেম ডিজাইন সাক্ষাৎকাৰ প্ৰশ্ন কেনেকৈ সমাধান কৰিব।

চিষ্টেম ডিজাইন সাক্ষাৎকাৰ হৈছে এটা উন্মুক্ত আলোচনা। আপোনাক ইয়াত নেতৃত্ব দিবলে আশা কৰা হয়।

আলোচনাটো পথ দেখুৱাবলৈ তলৰ পদক্ষেপবোৰ ব্যৱহাৰ কৰিব পাৰে। এই প্ৰক্ৰিয়া দৃঢ় কৰিবলৈ, সমাধানসহ চিষ্টেম ডিজাইন সাক্ষাৎকাৰ প্ৰশ্ন অংশটো তলৰ পদক্ষেপ ব্যৱহাৰ কৰি অনুশীলন কৰক।

পদক্ষেপ ১: ব্যৱহাৰ ক্ষেত্ৰ, সীমাবদ্ধতা, আৰু অনুমানৰ সংক্ষিপ্তসাৰ

দৰকাৰী বিষয়বস্তু সংগ্ৰহ কৰক আৰু সমস্যাৰ সীমা স্থিৰ কৰক। ব্যৱহাৰ ক্ষেত্ৰ আৰু সীমাবদ্ধতা স্পষ্ট কৰিবলৈ প্ৰশ্ন কৰক। অনুমানসমূহ আলোচনা কৰক।

পদক্ষেপ ২: উচ্চ স্তৰৰ ডিজাইন তৈয়াৰ কৰক

সমূহ গুৰুত্বপূর্ণ অংশসহ উচ্চ স্তৰৰ ডিজাইনৰ সংক্ষিপ্তসাৰ দিয়ক।

পদক্ষেপ ৩: মূল উপাদানসমূহ ডিজাইন কৰক

প্ৰত্যেকটা মূল উপাদানৰ বাবে বিস্তারিতভাৱে আলোচনা কৰক। উদাহৰণস্বৰূপে, যদি আপোনাক [এটা URL সংক্ষিপ্তকৰণ সেৱা ডিজাইন কৰিবলৈ] (https://raw.githubusercontent.com/donnemartin/system-design-primer/master/solutions/system_design/pastebin/README.md) অনুৰোধ কৰা হয়, তেন্তে আলোচনা কৰক:

পদক্ষেপ ৪: ডিজাইনটো স্কেল কৰক

বটলনেক চিনাক্ত কৰক আৰু সমাধান কৰক, দিয়া সীমাবদ্ধতাসমূহ অনুসৰি। উদাহৰণস্বৰূপে, scalability সমস্যা সমাধান কৰিবলৈ আপোনাৰ নিম্নলিখিতবোৰৰ প্ৰয়োজন আছে নেকি?

সম্ভৱপৰ সমাধান আৰু ট্রেড-অফসমূহ আলোচনা কৰক। প্ৰতিটো বিষয়েই এটা ট্রেড-অফ। [স্কেলেবল চিষ্টেম ডিজাইনৰ মূলনীতি] (#index-of-system-design-topics) ব্যৱহাৰ কৰি বটলনেক সমাধান কৰক।

চটপট গণনা

আপোনাক হাতে-কলমে কিছুমান অনুমান কৰিব পৰা যায়। Appendixত নিম্নলিখিত উৎসসমূহত চাওক:

উৎস(সমূহ) আৰু অধিক পঢ়াৰ বাবে

তলত দিয়া লিংকসমূহ চাওক, কি আশা কৰিব পাৰি তাৰ ভাল ধাৰণা পাবলৈ:

ছিষ্টেম ডিজাইন ইণ্টাৰ্ভিউ প্ৰশ্নসমূহ উত্তৰৰ সৈতে

সাধাৰণ ছিষ্টেম ডিজাইন ইণ্টাৰ্ভিউৰ প্ৰশ্নসমূহৰ উদাহৰণীয়া আলোচনা, ক’ড আৰু চিত্ৰ।
>
উত্তৰসমূহ solutions/ ফোল্ডাৰৰ সমলত সংলগ্ন।

| প্ৰশ্ন | | |---|---| | Pastebin.com (বা Bit.ly) ডিজাইন কৰক | উত্তৰ | | Twitter timeline আৰু search (বা Facebook feed আৰু search) ডিজাইন কৰক | উত্তৰ | | এটা web crawler ডিজাইন কৰক | উত্তৰ | | Mint.com ডিজাইন কৰক | উত্তৰ | | এজন সামাজিক জালৰ data structures ডিজাইন কৰক | উত্তৰ | | এটা search engine ৰ বাবে key-value store ডিজাইন কৰক | উত্তৰ | | Amazon ৰ sales ranking by category বৈশিষ্ট্য ডিজাইন কৰক | উত্তৰ | | AWS-ত মিলিয়ন সংখ্যক ব্যৱহাৰকাৰীৰ বাবে scalable ছিষ্টেম ডিজাইন কৰক | উত্তৰ | | এটা ছিষ্টেম ডিজাইন প্ৰশ্ন যোগ কৰক | অংদান কৰক |

Pastebin.com (বা Bit.ly) ডিজাইন কৰক

অভ্যাস আৰু উত্তৰ চাওক

Imgur

Twitter timeline আৰু search (বা Facebook feed আৰু search) ডিজাইন কৰক

অভ্যাস আৰু উত্তৰ চাওক

Imgur

এটা web crawler ডিজাইন কৰক

অভ্যাস আৰু উত্তৰ চাওক

Imgur

Design Mint.com

View exercise and solution

Imgur

Design the data structures for a social network

View exercise and solution

Imgur

Design a key-value store for a search engine

View exercise and solution

Imgur

Design Amazon's sales ranking by category feature

View exercise and solution

Imgur

Design a system that scales to millions of users on AWS

View exercise and solution

Imgur

Object-oriented design interview questions with solutions

Common object-oriented design interview questions with sample discussions, code, and diagrams.
>
Solutions linked to content in the solutions/ folder.

>Note: This section is under development

| Question | | |---|---| | এটা হেশ্‌ মেপ ডিজাইন কৰক | সমাধান | | এটা লিষ্ট ৰিছেণ্টলি ইউজড কেছ ডিজাইন কৰক | সমাধান | | এটা কল চেন্টাৰ ডিজাইন কৰক | সমাধান | | এটা কাৰ্ডৰ ডেক ডিজাইন কৰক | সমাধান | | এটা পাৰ্কিং লট ডিজাইন কৰক | সমাধান | | এটা চেট ছাৰ্ভাৰ ডিজাইন কৰক | সমাধান | | এটা চাৰ্কুলাৰ এৰে ডিজাইন কৰক | অংশগ্ৰহণ কৰক | | এটা অবজেক্ট-অৰিয়েন্টেড ডিজাইন প্ৰশ্ন যোগ কৰক | অংশগ্ৰহণ কৰক |

ছিষ্টেম ডিজাইন বিষয়বস্তু: ইয়াৰে আৰম্ভ কৰক

ছিষ্টেম ডিজাইনত নতুন?

প্ৰথমে, সাধাৰণ নীতিসমূহৰ মূল কথা বুজিব লাগিব, কি সিহঁত, কেনেকৈ ব্যৱহাৰ কৰা হয়, আৰু সিহঁতৰ লাভ-অলাভ।

পদক্ষেপ ১: স্কেলেবিলিটি ভিডিঅ' লেকচাৰ পৰ্যালোচনা কৰক

হাৰ্ভাৰ্ডত স্কেলেবিলিটি লেকচাৰ

পদক্ষেপ ২: স্কেলেবিলিটি প্ৰবন্ধ পৰ্যালোচনা কৰক

স্কেলেবিলিটি

পৰৱৰ্তী পদক্ষেপ

পিছত, আমি উচ্চ-স্তৰৰ বাণিজ্যিক সমঝোতা সমূহ চাওঁ:

মনে ৰাখিব যে সকলোবোৰে এটা সমঝোতা।

তেতিয়া আমি অধিক নিৰ্দিষ্ট বিষয়সমূহ যেনে DNS, CDN আৰু লোড বেলেন্সাৰ চাম।

কাৰ্যক্ষমতা বনাম বিস্তাৰযোগ্যতা

এটা সেৱা বিস্তাৰযোগ্য যদি ইয়াত সংযোজিত সম্পদৰ অনুপাতে কাৰ্যক্ষমতা বৃদ্ধি পায়। সাধাৰণতে, কার্যক্ষমতা বৃদ্ধি মানে অধিক কামৰ একক সেৱন কৰা, কিন্তু ই ডেটাসেট ডাঙৰ হ'লে ডাঙৰ কামৰ একক হেণ্ডেল কৰাটোও হ'ব পাৰে।1

কাৰ্যক্ষমতা বনাম বিস্তাৰযোগ্যতা বুজাৰ আন এটা উপায়:

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

বিলম্ব বনাম থ্ৰুপুট

বিলম্ব হৈছে কোনো কাৰ্য্য সম্পাদন কৰিবলৈ বা ফলাফল উত্পন্ন কৰিবলৈ সময়ৰ প্ৰয়োজন।

থ্ৰুপুট হৈছে এই ধৰণৰ কার্য্য বা ফলাফলৰ সংখ্যা একক সময়ত।

সাধাৰণতে, আপোনাই সৰ্বাধিক থ্ৰুপুট লক্ষ্য কৰা উচিত গ্ৰহণযোগ্য বিলম্বৰ সৈতে।

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

উপলব্ধতা বনাম সুসংগতিতা

CAP তত্ত্ব


উৎস: CAP তত্ত্ব পুনৰ আলোচনা

এখন বিতৰণ কৰা কম্পিউটাৰ প্ৰণালীত, আপুনি তলত দিয়া তিনিটা নিশ্চয়তাৰ ভিতৰত কেৱল দুটা মাত্ৰ সমৰ্থন কৰিব পাৰে:

নেটৱৰ্ক অৱিশ্বাস্য, গতিকে আপোনাক বিভাজন সহনশীলতা সমৰ্থন কৰিব লাগিব। আপোনাক ছফ্টৱেৰ হিচাপে সঙ্গততা আৰু উপলব্ধতাৰ মাজত বাণিজ্যিক সমঝোতা কৰিব লাগিব।

#### CP - সঙ্গততা আৰু বিভাজন সহনশীলতা

বিভাজিত নোডৰ পৰা প্ৰতিক্ৰিয়া বিচাৰোতে সময় শেষৰ ত্ৰুটি দেখা দিব পাৰে। আপোনাৰ ব্যৱসায়িক দাবীত যদিহে এটমিক পঢ়া আৰু লিখা প্ৰয়োজন, CP এটা ভাল বিকল্প।

#### AP - উপলব্ধতা আৰু বিভাজন সহনশীলতা

প্ৰতিক্ৰিয়াবোৰ যিকোনো নোডত উপলব্ধ থকা আটাইতকৈ সহজ তথ্যৰ সংস্কৰণ প্ৰদান কৰে, যি আটাইতকৈ নতুন নাও হ’ব পাৰে। লিখাবোৰ বিভাজন সমাধান হোৱাৰ পিছত কিছু সময় লৈ প্ৰসাৰিত হ’ব পাৰে।

AP ভাল বিকল্প যদি ব্যৱসায়িক দাবীত অৱশেষত সঙ্গততা অনুমোদন কৰিব লাগে বা প্ৰণালীয়ে বাহ্যিক ত্ৰুটিতো চলি থাকিব লাগে।

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

সঙ্গততাৰ পেটাৰ্নসমূহ

এটা তথ্যৰ একাধিক প্ৰতিলিপি থকা অৱস্থাত, আমাক সেইবোৰ কেনেকৈ সমন্বয় কৰিব লাগে যাতে গ্ৰাহকে তথ্যৰ সঙ্গত দৃশ্য পায়, সেই বাছনি কৰিব লাগে। CAP তত্ত্ব-ৰ পৰা সঙ্গততাৰ সংজ্ঞা মনত ৰাখিব - প্ৰতিটো পঢ়াইয়ে আটাইতকৈ নতুন লিখন অথবা এটা ত্ৰুটি লাভ কৰে।

দুর্বল সঙ্গততা

এটা লিখাৰ পিছত, পঢ়াবোৰে সেইটো দেখা পাব বা নাপাব পাৰে। এটা সৰ্বোত্তম চেষ্টা কৰা হয়।

এই পদ্ধতি memcached আদিত দেখা যায়। দুর্বল সঙ্গততা বাস্তৱ সময়ৰ ব্যৱহাৰৰ ক্ষেত্ৰত ভালদৰে কাম কৰে, যেনে VoIP, ভিডিঅ’ চেট, আৰু realtime multiplayer গেম। উদাহৰণস্বৰূপ, যদি আপুনি ফোনত কথাবতৰা কৰি আছে আৰু কিছু সময়ৰ বাবে সংযোগ হেৰাই পেলায়, সংযোগ পুনৰ লাভ কৰোঁতে সংযোগ হেৰোৱাৰ সময়ত কোৱা কথা আপুনি শুনা নাপায়।

অৱশেষত এক-ৰূপতা (Eventual consistency)

এখন লিখাৰ পিছত, পঢ়া-সমূহে শেষত সেইটো দেখিব (সাধাৰণতে মিলি ছেকেণ্ডৰ ভিতৰত)। ডাটা অসমান্তৰালভাৱে প্ৰতিৰূপিত হয়।

এই পদ্ধতি DNS আৰু ই-মেইল দৰে ব্যৱস্থাত দেখা যায়। অৱশেষত এক-ৰূপতা উচ্চ উপলভ্যতা থকা ব্যৱস্থাত ভালকৈ কাম কৰে।

শক্তিশালী এক-ৰূপতা (Strong consistency)

এখন লিখাৰ পিছত, পঢ়া-সমূহে সেইটো দেখিব। ডাটা সমান্তৰালভাৱে প্ৰতিৰূপিত হয়।

এই পদ্ধতি ফাইল চিস্টেম আৰু RDBMS-ত দেখা যায়। শক্তিশালী এক-ৰূপতা লেন-দেনৰ প্ৰয়োজন থকা ব্যৱস্থাত ভালকৈ কাম কৰে।

উৎস(সমূহ) আৰু অধিক পঢ়া

উপলভ্যতা পেটাৰ্ণসমূহ

উচ্চ উপলভ্যতা সহায় কৰিবলৈ দুটা সম্পূৰক পেটাৰ্ণ আছে: ফেইল-ওভাৰ আৰু প্ৰতিৰূপণ।

ফেইল-ওভাৰ

#### সক্ৰিয়-নিষ্ক্ৰিয় (Active-passive)

সক্ৰিয়-নিষ্ক্ৰিয় ফেইল-ওভাৰত, হৃদস্পন্দন (heartbeat) সক্ৰিয় আৰু ষ্টেন্ডবাই থকা নিষ্ক্ৰিয় ছাৰ্ভাৰৰ মাজত পঠোৱা হয়। যদি হৃদস্পন্দন বন্ধ হয়, নিষ্ক্ৰিয় ছাৰ্ভাৰ সক্ৰিয়ৰ IP ঠিকনা লৈ সেৱা আৰম্ভ কৰে।

ডাউনটাইমৰ দৈৰ্ঘ্য নিৰ্ধাৰণ কৰা হয় নিষ্ক্ৰিয় ছাৰ্ভাৰ 'হট' ষ্টেন্ডবাইত চলি আছে নে 'কোল্ড' ষ্টেন্ডবাইৰ পৰা আৰম্ভ কৰিব লাগিব। কেৱল সক্ৰিয় ছাৰ্ভাৰেই ট্ৰাফিক ব্যৱস্থাপনা কৰে।

সক্ৰিয়-নিষ্ক্ৰিয় ফেইল-ওভাৰক মাষ্টাৰ-চ্লেভ ফেইল-ওভাৰ বুলি কোৱা হয়।

#### সক্ৰিয়-সক্ৰিয় (Active-active)

সক্ৰিয়-সক্ৰিয়ত, দুয়োটা ছাৰ্ভাৰেই ট্ৰাফিক ব্যৱস্থাপনা কৰে, লোডৰ ভাগ-বতৰা কৰে।

যদি ছাৰ্ভাৰসমূহ পাব্লিক-মুখী হয়, DNS-এ দুয়োটা ছাৰ্ভাৰৰ পাব্লিক IP জানিব লাগিব। যদি ছাৰ্ভাৰসমূহ আন্তঃ-ৰূপে মুখী হয়, এপ্লিকেচন লজিক-এ দুয়োটা ছাৰ্ভাৰৰ বিষয়ে জানিব লাগিব।

সক্ৰিয়-সক্ৰিয় ফেইল-ওভাৰক মাষ্টাৰ-মাষ্টাৰ ফেইল-ওভাৰ বুলি কোৱা হয়।

অপৰিসীম(সমূহ): ফেইল-ওভাৰ

প্ৰতিলিপি

#### মাষ্টাৰ-চাকৰ আৰু মাষ্টাৰ-মাষ্টাৰ

এই বিষয়টো ডাটাবেছ অনুচ্ছেদত অধিক আলোচনা কৰা হৈছে:

সংখ্যাত উপলভ্যতা

উপলভ্যতা সাধাৰণতে আপটাইম (বা ডাউনটাইম) হিচাপে শতাংশৰ দ্বাৰা পৰিমাপ কৰা হয়, অৰ্থাৎ সেৱা উপলভ্য থকা সময়ৰ শতাংশ। উপলভ্যতা সাধাৰণতে 9 সংখ্যাৰ দ্বাৰা মাপা হয়--99.99% উপলভ্যতা থকা সেৱা চাৰিটা 9 আছে বুলি বৰ্ণনা কৰা হয়।

#### 99.9% উপলভ্যতা - তিনি 9

| সময়কাল | গ্ৰহণযোগ্য ডাউনটাইম| |----------------------|--------------------| | বছৰত ডাউনটাইম | 8ঘণ্টা 45মিনিট 57ছেকেণ্ড | | মাহত ডাউনটাইম | 43মিনিট 49.7ছেকেণ্ড | | সপ্তাহত ডাউনটাইম | 10মিনিট 4.8ছেকেণ্ড | | দিনত ডাউনটাইম | 1মিনিট 26.4ছেকেণ্ড |

#### 99.99% উপলভ্যতা - চাৰি 9

| সময়কাল | গ্ৰহণযোগ্য ডাউনটাইম| |----------------------|--------------------| | বছৰত ডাউনটাইম | 52মিনিট 35.7ছেকেণ্ড | | মাহত ডাউনটাইম | 4মিনিট 23ছেকেণ্ড | | সপ্তাহত ডাউনটাইম | 1মিনিট 5ছেকেণ্ড | | দিনত ডাউনটাইম | 8.6ছেকেণ্ড |

#### সমান্তৰালত আৰু ক্ৰমান্বয়ে উপলভ্যতা

যদি এটা সেৱা বহুতো উপাদানৰে গঠিত যি বিফল হোৱাৰ সম্ভাৱনা আছে, তেন্তে সেৱাটোৰ সামগ্ৰিক উপলভ্যতা নিৰ্ভৰ কৰে উপাদানসমূহ ক্ৰমান্বয়ে বা সমান্তৰালত আছে নে নাই।

###### ক্ৰমান্বয়ে যেতিয়া ১০০%তকৈ কম উপলব্ধতাৰ সৈতে দুটা উপাদান শৃংখলাবদ্ধভাৱে থাকে, তেতিয়া সামগ্ৰিক উপলব্ধতা হ্ৰাস হয়:

Availability (Total) = Availability (Foo) * Availability (Bar)

যদি Foo আৰু Bar দুয়োটা ৯৯.৯% উপলব্ধতা থকা হয়, তেন্তে তেওঁলোকৰ ক্ৰমিক মুঠ উপলব্ধতা ৯৯.৮% হ’ব।

###### সমান্তৰালভাৱে

যেতিয়া উপলব্ধতা < ১০০% থকা দুইটা অংশ সমান্তৰালভাৱে থাকে, মুঠ উপলব্ধতা বৃদ্ধি পায়:

Availability (Total) = 1 - (1 - Availability (Foo)) * (1 - Availability (Bar))
যদি Foo আৰু Bar দুয়োটাৰ ৯৯.৯% উপলব্ধতা থাকে, তেন্তে তেওঁলোকৰ মুঠ উপলব্ধতা সমান্তৰালভাৱে ৯৯.৯৯৯৯% হ’ব।

ড’মেইন নাম ছিষ্টেম


উৎস: DNS সুৰক্ষা প্ৰেজেন্টেচন

এটা ড’মেইন নাম ছিষ্টেম (DNS) এ www.example.com যেনে এটা ড’মেইন নামক এটা IP ঠিকনালৈ অনুবাদ কৰে।

DNS গঠনগতভাৱে হায়াৰাৰ্কিকেল, ওপৰৰ স্তৰত কিছুমান অথৰিটেটিভ ছাৰ্ভাৰ থাকে। আপোনাৰ ৰাউটাৰ বা ISP-এ DNS ছাৰ্ভাৰ(সমূহ)ৰ তথ্য দিয়ে lookup কৰাৰ সময়ত। তলৰ স্তৰৰ DNS ছাৰ্ভাৰসমূহে মেপিংসমূহ cache কৰে, যি DNS propagation বিলম্বৰ বাবে পুৰণি হ’ব পাৰে। DNS ফলাফলসমূহ আপোনাৰ ব্ৰাউজাৰ বা OS-এও এটা নিৰ্দিষ্ট সময়ৰ বাবে cache কৰিব পাৰে, যি time to live (TTL) দ্বাৰা নিৰ্ধাৰিত।

CloudFlare আৰু Route 53 যেনে সেৱাসমূহে পৰিচালিত DNS সেৱা প্ৰদান কৰে। কিছুমান DNS সেৱাই বিভিন্ন পদ্ধতিৰে ট্ৰেফিক ৰাউট কৰিব পাৰে:

অসুবিধা(সমূহ): DNS

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

কন্টেন্ট ডেলিভাৰী নেটৱৰ্ক


উৎস: কিয় CDN ব্যৱহাৰ কৰিব

এটা কন্টেন্ট ডেলিভাৰী নেটৱৰ্ক (CDN) হৈছে বিশ্বব্যাপী বিতৰিত প্ৰক্সি ছাৰ্ভাৰৰ এক নেটৱৰ্ক, যি ব্যৱহাৰকাৰীৰ ওচৰৰ স্থানসমূহৰ পৰা কন্টেন্ট প্ৰদান কৰে। সাধাৰণতে, HTML/CSS/JS, ফটো, আৰু ভিডিঅ'ৰ দৰে ষ্টেটিক ফাইল CDN ৰ পৰা প্ৰদান কৰা হয়, যদিও Amazon ৰ CloudFront ৰ দৰে কিছুমান CDN-এ ডাইনামিক কন্টেন্ট সমৰ্থন কৰে। চাইটৰ DNS ৰিজলিউচনে ক্লায়েন্টক কোন ছাৰ্ভাৰৰ সৈতে যোগাযোগ কৰিব সেইটো জনায়।

CDN ৰ পৰা কন্টেন্ট প্ৰদান কৰোঁতে দুটা উপায়ত কার্যক্ষমতা যথেষ্ট বৃদ্ধি কৰিব পাৰে:

পুশ CDN

পুশ CDN-এ আপোনাৰ ছাৰ্ভাৰত পৰিৱৰ্তন ঘটিলে নতুন কন্টেন্ট লাভ কৰে। আপুনি সম্পূৰ্ণ দায়িত্ব লৈ কন্টেন্ট প্ৰদান কৰে, CDN ত সোজাকৈ আপলোড কৰে আৰু URL সমূহ CDN ত নির্দেশ কৰে। আপুনি কন্টেন্ট কেতিয়া মেয়াদ উত্তীর্ণ হ'ব আৰু কেতিয়া আপডেট হ'ব, সেইটো নিৰ্ধাৰণ কৰিব পাৰে। কন্টেন্ট কেৱল নতুন বা পৰিৱৰ্তিত হ'লে আপলোড কৰা হয়, ফলত ট্ৰাফিক কম হয়, কিন্তু ষ্ট'ৰেজ বৃদ্ধি পায়।

অল্প পৰিমাণৰ ট্ৰাফিক থকা চাইট অথবা যি চাইটত কন্টেন্ট প্ৰায়ে আপডেট নহয়, সেইবোৰ পুশ CDN ৰ সৈতে ভালকৈ কাম কৰে। কন্টেন্ট এটা বাৰ CDN ত ৰাখা হয়, নিয়মীয়াকৈ পুনৰ-পুল কৰা নহয়।

পুল CDN

পুল CDN-এ প্ৰথম ব্যৱহাৰকাৰীয়ে কন্টেন্ট অনুৰোধ কৰিলে আপোনাৰ ছাৰ্ভাৰৰ পৰা নতুন কন্টেন্ট গ্ৰহণ কৰে। আপুনি কন্টেন্ট আপোনাৰ ছাৰ্ভাৰত ৰাখে আৰু URL সমূহ CDN ত নির্দেশ কৰে। এইটোত CDN ত কেচ কৰা নোহোৱা পৰ্যন্ত অনুৰোধটো অলপ মন্থৰ হয়।

এটা time-to-live (TTL) নিৰ্ধাৰণ কৰে কিমান সময় কন্টেন্ট কেচ কৰা হ'ব। পুল CDN-এ CDN ত ষ্ট'ৰেজ স্পেচ কম কৰে, কিন্তু যদি ফাইলসমূহ মেয়াদ উত্তীর্ণ হয় আৰু পুনৰ পুল কৰা হয়, তেন্তে অপ্ৰয়োজনীয় ট্ৰাফিক সৃষ্টি কৰিব পাৰে।

বেছি ট্ৰাফিক থকা চাইটসমূহ পুল CDN ৰ সৈতে ভাল কাম কৰে, কাৰণ ট্ৰাফিক অধিক সমভাৱে বিতৰণ হয় আৰু কেৱল নতুন অনুৰোধ কৰা কন্টেন্ট CDN ত থাকে।

অসুবিধা(সমূহ): CDN

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

লোড বেলেন্সাৰ


উৎস: স্কেলেবেল চিষ্টেম ডিজাইন প্যাটাৰ্ন

লোড বেলেন্সাৰসমূহে আহি থকা ক্লায়েন্ট অনুৰোধসমূহ কম্পিউটিং ৰিসোৰ্চ যেনে এপ্লিকেশ্বন ছাৰ্ভাৰ আৰু ডেটাবেছলৈ বিতৰণ কৰে। প্ৰতিটো ক্ষেত্ৰত, লোড বেলেন্সাৰে কম্পিউটিং ৰিসোৰ্চৰ পৰা উত্তৰ উপযুক্ত ক্লায়েন্টলৈ পঠিয়ায়। লোড বেলেন্সাৰসমূহ ইয়াত কাৰ্যকৰী:

লোড বেলেন্সাৰসমূহ হাৰ্ডৱেৰ (মূল্যবান) বা HAProxy সদৃশ ছফটৱেৰ ব্যৱহাৰ কৰি প্ৰয়োগ কৰিব পাৰি।

অতিৰিক্ত সুবিধাসমূহ অন্তর্ভুক্ত:

বিফলতাৰ পৰা সুৰক্ষিত থাকিবলৈ, সাধাৰণতে বহু লোড বেলেন্সাৰ সংস্থাপন কৰা হয়, active-passive বা active-active মুডত।

লোড বেলেন্সাৰসমূহে বিভিন্ন মেট্ৰিকৰ আধাৰত ট্ৰাফিক ৰাউট কৰিব পাৰে, যেনে:

Layer 4 লোড বেলেন্সিং

Layer 4 লোড বেলেন্সাৰসমূহে ট্ৰান্সপৰ্ট স্তৰ-ৰ তথ্য চাই অনুৰোধসমূহ কেনেদৰে বিতৰণ কৰিব সিদ্ধান্ত লয়। সাধাৰণতে, ইয়াত উৎস, গন্তব্য IP ঠিকনা, আৰু হেডাৰত থকা পোৰ্ট অন্তর্ভুক্ত, কিন্তু পেকেটৰ বিষয়বস্তু নহয়। Layer 4 লোড বেলেন্সাৰসমূহে নেটৱৰ্ক পেকেটসমূহ আপষ্ট্ৰিম ছাৰ্ভাৰলৈ আগবঢ়ায়, Network Address Translation (NAT) সম্পাদন কৰে।

Layer 7 লোড বেলেন্সিং

লেয়াৰ ৭ ল'ড বেলেন্সাৰসমূহে এপ্লিকেশ্যন স্তৰ চাই অনুৰোধসমূহ কেনেদৰে বিতৰণ কৰিব সেইটো সিদ্ধান্ত লয়। এইটোত হেডাৰ, মেছেজ, আৰু কুকীৰ বিষয়বস্তু অন্তর্ভুক্ত কৰিব পাৰে। লেয়াৰ ৭ ল'ড বেলেন্সাৰসমূহে নেটৱৰ্ক ট্ৰাফিক শেষ কৰে, মেছেজ পঢ়ে, ল'ড-বেলেন্সিং সিদ্ধান্ত লয়, তাৰপিছত নিৰ্বাচিত ছাৰ্ভাৰত সংযোগ খোল। উদাহৰণস্বৰূপে, এটা লেয়াৰ ৭ ল'ড বেলেন্সাৰে ভিডিঅ' ট্ৰাফিক ভিডিঅ' হোস্ট কৰা ছাৰ্ভাৰলৈ পঠিয়াব পাৰে আৰু অধিক সংবেদনশীল ইউজাৰ বিলিং ট্ৰাফিক সুৰক্ষিত ছাৰ্ভাৰলৈ পঠিয়াব পাৰে।

লচিলতাৰ মূল্যত, লেয়াৰ ৪ ল'ড বেলেন্সিংয়ে লেয়াৰ ৭তকৈ কম সময় আৰু কম কম্পিউটিং সম্পদৰ প্ৰয়োজন, যদিও আধুনিক কমোডিটি হার্ডৱেৰত প্ৰদৰ্শন প্ৰভাৱ ন্যূনতম হ’ব পাৰে।

অনুভূমিক স্কেলিং

ল'ড বেলেন্সাৰসমূহে অনুভূমিক স্কেলিঙতো সহায় কৰিব পাৰে, যাৰ ফলত প্ৰদৰ্শন আৰু উপলভ্যতা বৃদ্ধি পায়। কমোডিটি মেচিন ব্যৱহাৰ কৰি স্কেল আউট কৰাটো অধিক ব্যয়-সাশ্ৰয়ী আৰু অধিক উপলভ্যতা প্রদান কৰে, একেটা ছাৰ্ভাৰৰ মূল্যবান হার্ডৱেৰত স্কেল আপ কৰাতকৈ, যাক Vertical Scaling বুলি কোৱা হয়। লগতে, কমোডিটি হার্ডৱেৰত কাম কৰা প্ৰতিভা নিয়োগ কৰাটো বিশেষজ্ঞ এণ্টাৰপ্ৰাইজ চিস্টেমতকৈ সহজ।

#### অসুবিধা(সমূহ): অনুভূমিক স্কেলিং

অসুবিধা(সমূহ): ল'ড বেলেন্সাৰ

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

ৰিভাৰ্ছ প্ৰক্সি (ৱেব ছাৰ্ভাৰ)


উৎস: উইকিপিডিয়া

এখন ৰিভাৰ্ছ প্ৰক্সি হৈছে এটা ৱেব ছাৰ্ভাৰ যি আন্তঃৰ্ভুক্ত সেৱাসমূহ কেন্দ্রীকৃত কৰে আৰু জনসাধাৰণৰ বাবে একত্ৰিত ইণ্টাৰফেছ প্ৰদান কৰে। ক্লায়েন্টৰ পৰা অহা অনুৰোধসমূহ ছাৰ্ভাৰলৈ আগবঢ়োৱা হয় যি সেই অনুৰোধ পূৰণ কৰিব পাৰে, তাৰ পিছত ৰিভাৰ্ছ প্ৰক্সিয়ে ছাৰ্ভাৰৰ প্ৰতিক্ৰিয়া ক্লায়েন্টলৈ ঘূৰাই দিয়ে।

অতিৰিক্ত লাভসমূহৰ ভিতৰত আছে:

ল’ড বেলেন্সাৰ বনাম ৰিভাৰ্ছ প্ৰক্সি

অসুবিধা(সমূহ): ৰিভাৰ্ছ প্ৰক্সি

উৎস(সমূহ) আৰু অধিক পঢ়া

এপ্লিকেশ্যন স্তৰ


উৎস: স্কেলৰ বাবে ছিষ্টেম আৰ্হি কৰোতে পৰিচয়

ৱেব স্তৰটো এপ্লিকেশ্বন স্তৰৰ পৰা (যাক প্লেটফৰ্ম স্তৰো বুলি জনা যায়) পৃথক কৰা হ’লে আপুনি দুয়োটা স্তৰক স্বাধীনভাৱে স্কেল আৰু কনফিগাৰ কৰিব পাৰে। নতুন API যোগ কৰিলে, প্ৰয়োজনত নতুন ৱেব ছাৰ্ভাৰ যোগ নকৰাকৈ এপ্লিকেশ্বন ছাৰ্ভাৰ যোগ হয়। একক দায়িত্ব নীতি সৰু আৰু স্বায়ত্ত্বশাসিত সেৱাসমূহৰ বাবেই উৎসাহিত কৰে যি একেলগে কাম কৰে। সৰু দলে সৰু সেৱাসমূহৰ সৈতে দ্ৰুত বৃদ্ধি পোৱাৰ বাবে অধিক আগ্ৰাসীভাৱে পৰিকল্পনা কৰিব পাৰে।

এপ্লিকেশ্বন স্তৰৰ কৰ্মচাৰীয়ে অসিঙ্ক্ৰনতা সক্ষম কৰাত সহায় কৰে।

মাইক্ৰ’চাৰ্ভিচ

এই আলোচনা সংক্রান্ত মাইক্ৰ’চাৰ্ভিচ, যাক স্বাধীনভাৱে ডিপ্লয় কৰিব পৰা, সৰু, মডুলাৰ সেৱাসমূহৰ এক ছুট হিচাপে বৰ্ণনা কৰিব পাৰি। প্ৰতিটো সেৱাই এটা অনন্য প্ৰক্ৰিয়া চলায় আৰু এটা সু-সংজ্ঞায়িত, হালকা-ওজনৰ ব্যৱস্থাৰে যোগাযোগ কৰে যাতে ব্যৱসায়িক লক্ষ্য পূৰণ হয়। 1

Pinterest-ৰ উদাহৰণত, তলত দিয়া মাইক্ৰ’চাৰ্ভিচসমূহ থাকিব পাৰে: ব্যৱহাৰকাৰী প্ৰ’ফাইল, ফলোৱৰ, ফিড, সন্ধান, ফটো আপলোড, আদি।

সেৱা সন্ধান

Consul, Etcd, আৰু Zookeeper যেনে ছিষ্টেমসমূহে নাম, ঠিকনা, আৰু পোৰ্টৰ ৰেজিষ্ট্ৰেশ্বন ৰখা কাৰ্যদ্বাৰা সেৱাসমূহে একে-অন্যক বিচাৰি পোৱাৰ সহায় কৰে। Health checks-এ সেৱা অখণ্ডতা যাচাই কৰাত সহায় কৰে আৰু সাধাৰণতে এটা HTTP এণ্ডপইণ্ট ব্যৱহাৰ কৰে। Consul আৰু Etcd-এ key-value store অন্তর্নিহিত আছে যি কনফিগ মান আৰু অন্যান্য ভাগ-বতৰা ডাটা সংৰক্ষণত সহায়ক।

অসুবিধাসমূহ: এপ্লিকেশ্বন স্তৰ

উৎস আৰু অধিক পঢ়া

ডাটাবেছ


উৎস: আপোনাৰ প্ৰথম ১০ নিযুত ব্যৱহাৰকাৰীৰ বাবে স্কেলিং

ৰিলেচনেল ডাটাবেছ মেনেজমেণ্ট ছিষ্টেম (RDBMS)

এখন রিলেচনেল ডেটাবেছ যেনে SQL হৈছে টেবুলত সংগঠিত ডেটা আইটেমৰ এটা সংগ্ৰহ।

ACID হৈছে ৰিলেচনেল ডেটাবেছৰ ট্ৰানজেকচনৰ এটা গুণাবলী।

ৰিলেচনেল ডেটাবেছ স্কেল কৰিবলৈ বহু প্ৰযুক্তি আছে: মাষ্টাৰ-চ্লেভ ৰেপ্লিকেচন, মাষ্টাৰ-মাষ্টাৰ ৰেপ্লিকেচন, ফেডাৰেছন, শাৰ্ডিং, ডিনৰমেলাইজেচন, আৰু SQL টিউনিং।

#### মাষ্টাৰ-চ্লেভ ৰেপ্লিকেচন

মাষ্টাৰে ৰিড আৰু ৰাইট কৰে, আৰু ৰাইটবোৰ চ্লেভলৈ ৰেপ্লিকেট কৰে, যিয়ে কেৱল ৰিড কৰে। চ্লেভে আৰু অধিক চ্লেভলৈ ৰেপ্লিকেট কৰিব পাৰে গছৰ দৰে। যদি মাষ্টাৰ অফলাইন হয়, চিস্টেমে কেৱল ৰিড মুডত চলি থাকে যেতিয়ালৈকে চ্লেভক মাষ্টাৰত উন্নীত কৰা নহয় বা নতুন মাষ্টাৰ দিয়াৰ ব্যৱস্থা কৰা নহয়।


উৎস: Scalability, availability, stability, patterns

##### অসুবিধা(সমূহ): মাষ্টাৰ-চ্লেভ ৰেপ্লিকেচন

#### মাষ্টাৰ-মাষ্টাৰ ৰেপ্লিকেচন

উভয় মাষ্টাৰে ৰিড আৰু ৰাইট কৰে আৰু ৰাইটবোৰত পৰস্পৰে সমন্বয় কৰে। যদি যিকোনো মাষ্টাৰ ডাউন হয়, চিস্টেমে ৰিড আৰু ৰাইট দুয়ো চলাই ৰাখিব পাৰে।


উৎস: Scalability, availability, stability, patterns

##### অসুবিধা(সমূহ): মাষ্টাৰ-মাষ্টাৰ ৰেপ্লিকেচন

##### অসুবিধা(সমূহ): প্ৰতিলিপি

##### উৎস(সমূহ) আৰু অধিক পঢ়া: প্ৰতিলিপি

#### ফেডাৰেচন


উৎস: Scaling up to your first 10 million users

ফেডাৰেচন (অথবা functional partitioning) ডাটাবেইজসমূহক function অনুসৰি বিভাজিত কৰে। উদাহৰণস্বৰূপ, এটা single, monolithic ডাটাবেইজৰ পৰিৱর্তে, আপুনি তিনিটা ডাটাবেইজ ৰাখিব পাৰে: forums, users, আৰু products, যাৰ ফলত প্ৰতিটো ডাটাবেইজত read আৰু write traffic কম হয় আৰু সেই অনুসৰি প্ৰতিলিপি lag কম হয়। সৰু ডাটাবেইজৰ বাবে অধিক data memory-ত সংৰক্ষণ কৰিব পাৰি, যাৰ ফলত cache locality উন্নত হোৱাৰ বাবে অধিক cache hit হয়। কোনো এটা কেন্দ্ৰীয় master-এ write serialise নকৰাত আপুনি সমান্তৰালভাৱে লিখিব পাৰে, যাৰ ফলত throughput বাঢ়ে।

##### অসুবিধা(সমূহ): ফেডাৰেচন

##### উৎস(সমূহ) আৰু অধিক পঢ়া: ফেডাৰেচন

#### শাৰ্ডিং


উৎস: Scalability, availability, stability, patterns

Sharding-এ তথ্য বিৱিধ ডাটাবেছত বিতৰণ কৰা হয়, যাতে প্ৰতিটো ডাটাবেছ কেৱল তথ্যৰ এটা অংশহে পৰিচালনা কৰিব পাৰে। উদাহৰণস্বৰূপে, যদি এটা users database লৈ ধৰা হয়, ব্যৱহাৰকাৰীৰ সংখ্যা বৃদ্ধি হোৱা অনুসৰি, ক্লাষ্টাৰত অধিক shard যোগ কৰা হয়।

federation-ৰ সুবিধাসমূহৰ দৰে, sharding-এ কম পঢ়া আৰু লিখা traffic, কম replication, আৰু অধিক cache hit ফলাফল কৰে। Index-ৰ আকাৰো কম হয়, যাৰ ফলত সাধাৰণতে query অধিক দ্ৰুত হয়। যদি এটা shard ডাউন হয়, আন shardবোৰ চলি থাকে, যদিও data loss ৰোধ কৰিবলৈ replication ব্যৱহাৰ কৰিব লাগিব। Federation-ৰ দৰে, ইয়াতো লিখা serialization কৰা এটা কেন্দ্ৰীয় master নাই, ফলত সমান্তৰালভাৱে লিখা সম্ভব আৰু throughput বৃদ্ধি হয়।

ব্যৱহাৰকাৰীৰ table shard কৰাৰ সাধাৰণ পদ্ধতি হৈছে ব্যৱহাৰকাৰীৰ নামৰ আৰম্ভণি অক্ষৰ বা ভূগোলিক স্থান অনুসৰি।

##### অসুবিধা(সমূহ): sharding

##### উৎস(সমূহ) আৰু অধিক পঢ়াৰ বাবে: sharding

#### Denormalization

Denormalization-এ কিছু লিখা performance-ৰ বিনিময়ত পঢ়াৰ performance উন্নত কৰিবলৈ চেষ্টা কৰে। তথ্যৰ অতিৰিক্ত প্ৰতিলিপি বহুবিধ table-ত লিখা হয়, যাতে ব্যয়বহুল join এড়াই যায়। PostgreSQL আৰু Oracle-ৰ দৰে কিছু RDBMS-এ materialized views সমৰ্থন কৰে, যিয়ে অতিৰিক্ত তথ্য সংৰক্ষণ আৰু প্ৰতিলিপি একে ৰাখিবলৈ কাম কৰে।

federation আৰু sharding-ৰ দৰে পদ্ধতিত তথ্য বিতৰণ হোৱাৰ পাছত, data center-ত join পৰিচালনা অধিক জটিল হয়। Denormalization-এ এনে জটিল join-ৰ প্ৰয়োজনীয়তা এড়াই যাব পাৰে।

বেশিভাগ ব্যৱস্থাত, পঢ়া লিখাৰ তুলনাত ১০০:১ বা ১০০০:১ হ’ব পাৰে। জটিল database join-ৰ ফলত পঢ়া খুব ব্যয়বহুল হ’ব পাৰে, আৰু disk operation-ত অধিক সময় ব্যয় হয়।

##### অসুবিধা(সমূহ): denormalization

###### উৎস(সমূহ) আৰু অধিক পঢ়াৰ বাবে: denormalization

#### SQL টিউনিং

SQL টিউনিং এটা বিস্তৃত বিষয় আৰু বহু কিতাপ ৰেফাৰেঞ্চ হিচাপে লিখা হৈছে।

বেঞ্চমাৰ্ক আৰু প্ৰ’ফাইল কৰা গুৰুত্বপূর্ণ যাতে বটলনেক চিহ্নিত আৰু অনুকৰণ কৰিব পাৰি।

বেঞ্চমাৰ্কিং আৰু প্ৰ’ফাইলিংয়ে নিম্নলিখিত অপ্টিমাইজেশ্যনসমূহৰ দিশে ইঙ্গিত দিব পাৰে।

##### স্কিমা আঁট কৰি লওক

##### ভাল ইনডেক্স ব্যৱহাৰ কৰক

##### খৰছযুক্ত join এড়াওক

##### টেবুলসমূহ partition কৰক

##### কুৱাৰী কেচ টিউন কৰক

##### উৎস(সমূহ) আৰু অধিক পঢ়া: SQL টিউনিং

NoSQL

NoSQL হৈছে তথ্যবস্তুৰ এক সংগ্ৰহ, যি key-value store, document store, wide column store, অথবা graph databaseৰ ৰূপত প্ৰতিনিধিত্ব কৰা হয়। তথ্য ডিনৰ্মেলাইজ কৰা হয়, আৰু সাধাৰণতে যোগ (join)বোৰ এপ্লিকেচন ক’ডত কৰা হয়। বেছিভাগ NoSQL ষ্টোৰত সত্যিকাৰ ACID লেন-দেন নাথাকে আৰু eventual consistencyক প্ৰাধান্য দিয়ে।

BASE সাধাৰণতে NoSQL ডাটাবেছৰ গুণাবলী বৰ্ণনা কৰিবলৈ ব্যৱহাৰ হয়। CAP Theoremৰ লগত তুলনা কৰিলে, BASE-এ consistencyৰ তুলনাত availabilityক বেছি প্ৰাধান্য দিয়ে।

SQL বা NoSQLত নিৰ্বাচন কৰাৰ উপৰিও, কোন ধৰণৰ NoSQL ডাটাবেছ আপোনাৰ ব্যৱহাৰৰ ক্ষেত্ৰ(সমূহ)ৰ বাবে ঠিক হব তাক বুজা উপযোগী। আমি পৰৱৰ্তী অংশত key-value stores, document stores, wide column stores, আৰু graph databases আলোচনা কৰিম।

#### Key-value store

Abstraction: hash table

Key-value store সাধাৰণতে O(1) পঢ়া আৰু লিখাৰ অনুমতি দিয়ে আৰু সাধাৰণতে মেমৰি বা SSDত সংৰক্ষিত থাকে। Data stores-এ lexicographic orderত key সংৰক্ষণ কৰিব পাৰে, যাতে key ৰেঞ্জ সহজে উদ্ধাৰ কৰিব পৰা যায়। Key-value store-এ মানৰ সৈতে metadata সংৰক্ষণৰ সুবিধা দিয়ে।

Key-value store-এ উচ্চ পাৰফৰ্মেন্স দিয়ে আৰু সাধাৰণ ডাটা মডেল বা দ্রুত পৰিবৰ্তন হোৱা তথ্য, যেনে in-memory cache layerৰ বাবে ব্যৱহাৰ কৰা হয়। কাৰণ এইবোৰে কেৱল সীমিত অপাৰেশ্যন দিয়া, অতিরিক্ত অপাৰেশ্যনৰ প্ৰয়োজন হলে জটিলতা এপ্লিকেচন স্তৰত সৰিয়াই যায়।

Key-value store হৈছে অধিক জটিল ব্যৱস্থাৰ আধাৰ, যেনে document store, আৰু কেতবোৰ ক্ষেত্ৰত graph database।

##### উৎস(সমূহ) আৰু অধিক পঢ়া: key-value store

#### ডকুমেন্ট সংৰক্ষণাগাৰ

বিমূর্ততা: কীৰ্তি-মূল্য সংৰক্ষণাগাৰ য'ত ডকুমেন্টসমূহ মূল্য হিচাপে সংৰক্ষিত

এটা ডকুমেন্ট সংৰক্ষণাগাৰ ডকুমেন্টক কেন্দ্ৰ কৰি গঠিত (XML, JSON, বাইনেৰী, আদি), য'ত এটা ডকুমেন্টে কোনো এটা অবজেক্টৰ সকলো তথ্য সংৰক্ষণ কৰে। ডকুমেন্ট সংৰক্ষণাগাৰে API অথবা প্ৰশ্ন ভাষা প্ৰদান কৰে যাৰ সহায়ত ডকুমেন্টৰ আন্তঃ গঠন অনুসৰি সন্ধান কৰিব পৰা যায়। মন কৰিব, বহু কেইটি কীৰ্তি-মূল্য সংৰক্ষণাগাৰে মূল্যৰ মেটাডেটা ব্যৱহাৰৰ সুবিধা থাকে, যাৰ ফলত এই দুটা সংৰক্ষণ ধৰণৰ সীমা অস্পষ্ট হৈ পৰে।

মৌলিক ৰূপত, ডকুমেন্টসমূহ সংগ্ৰহ, টেগ, মেটাডেটা, অথবা ডাইৰেক্টৰীৰ দ্বাৰা সজোৱা হয়। যদিও ডকুমেন্টসমূহ সংগঠিত বা গোট কৰা যায়, ডকুমেন্টসমূহৰ ক্ষেত্ৰসমূহ সম্পূৰ্ণ ভিন্ন হ'ব পাৰে।

কিছু ডকুমেন্ট সংৰক্ষণাগাৰ যেনে MongoDB আৰু CouchDB SQL সদৃশ ভাষা প্ৰদান কৰে জটিল সন্ধান কৰিবলৈ। DynamoDB কীৰ্তি-মূল্য আৰু ডকুমেন্ট দুয়োটা সমৰ্থন কৰে।

ডকুমেন্ট সংৰক্ষণাগাৰে উচ্চ নমনীয়তা প্ৰদান কৰে আৰু সাধাৰণতে কেতিয়াবা পৰিবৰ্তন হোৱা তথ্যৰ সৈতে কাম কৰিবলৈ ব্যৱহৃত হয়।

##### উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ: ডকুমেন্ট সংৰক্ষণাগাৰ

#### Wide column সংৰক্ষণাগাৰ


উৎস: SQL & NoSQL, এখন সংক্ষেপ ইতিহাস

বিমূর্ততা: nested map ColumnFamily>

Wide column সংৰক্ষণাগাৰৰ মূখ্য তথ্য একক হৈছে এটা কলাম (নাম/মূল্য জোৰ)। এটা কলাম কলাম পৰিয়ালত গোট কৰিব পৰা যায় (SQL টেবুলৰ সদৃশ)। Super column পৰিয়ালে আৰু অধিক কলাম পৰিয়াল গোট কৰে। আপুনি প্ৰত্যেক কলামক ৰ' কীৰ্তিৰে স্বাধীনভাৱে লাভ কৰিব পাৰে, আৰু একে ৰ' কীৰ্তিৰ কলামসমূহে ৰ' গঠন কৰে। প্ৰতিটো মূল্যত সংস্কৰণৰ বাবে আৰু দ্বন্দ্ব সমাধানৰ বাবে টাইমষ্টেম্প থাকে।

Google-এ Bigtable Wide column সংৰক্ষণাগাৰৰ প্ৰথম সংস্কৰণ হিচাপে উন্মোচন কৰিছিল, যিয়ে ওপেন-চ'র্স HBaseক প্ৰভাৱিত কৰিছে, যি সাধাৰণতে Hadoop ecosystem-ত ব্যৱহৃত হয়, আৰু Cassandra Facebook-ৰ পৰা। BigTable, HBase, আৰু Cassandra-ৰ দৰে সংৰক্ষণাগাৰে কীৰ্তিসমূহ লেক্সিকোগ্ৰাফিক অনুক্ৰমত ৰাখে, যাৰ সহায়ত নিৰ্বাচিত কীৰ্তিৰ পৰিসৰ সহজে উদ্ধাৰ কৰিব পৰা যায়।

Wide column সংৰক্ষণাগাৰে উচ্চ উপলব্ধতা আৰু উচ্চ স্কেলেবিলিটি প্ৰদান কৰে। ই সাধাৰণতে অতি বৃহৎ তথ্য সংগ্ৰহৰ বাবে ব্যৱহৃত হয়।

##### উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ: wide column সংৰক্ষণাগাৰ

#### গ্ৰাফ ডাটাবেচ


উৎস: গ্ৰাফ ডাটাবেচ

বিমূর্তকৰণ: গ্ৰাফ

এটা গ্ৰাফ ডাটাবেচত, প্ৰতিটো নোড এটা ৰেকৰ্ড আৰু প্ৰতিটো আৰ্ক দুটা নোডৰ মাজত এখন সম্পৰ্ক। গ্ৰাফ ডাটাবেচসমূহ জটিল সম্পৰ্ক, বহু বিদেশী চাবি অথবা বহু-ত-many সম্পৰ্ক দেখুওৱাত অপ্টিমাইজ কৰা।

গ্ৰাফ ডাটাবেচসমূহ জটিল সম্পৰ্ক থকা ডাটা মডেলত, যেনে এটা ছচিয়েল নেটৱৰ্কত, উচ্চ কাৰ্যক্ষমতা প্ৰদান কৰে। এইবোৰ তুলনামূলকভাৱে নতুন আৰু এতিয়াও ব্যাপকভাৱে ব্যৱহৃত নহয়; বিকাশৰ সঁজুলি আৰু উৎস পোৱা কঠিন হ’ব পাৰে। বহু গ্ৰাফ কেৱল REST API ৰ জৰিয়তে এক্সেছ কৰিব পাৰি।

##### উৎস(সমূহ) আৰু অধিক পঢ়িবৰ বাবে: গ্ৰাফ

#### উৎস(সমূহ) আৰু অধিক পঢ়িবৰ বাবে: NoSQL

SQL না NoSQL


উৎস: RDBMS ৰ পৰা NoSQL লৈ সলনি

SQL-ৰ কাৰণসমূহ:

NoSQL-ৰ কাৰণসমূহ:

NoSQL-ৰ বাবে উপযুক্ত নমুনা ডাটা:

##### উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ: SQL বা NoSQL

কেশ


উৎস: স্কেলেবল চিষ্টেম ডিজাইন পেটাৰ্ন

কেচিংয়ে পৃষ্ঠা লোড সময় উন্নত কৰে আৰু আপোনাৰ ছাৰ্ভাৰ আৰু ডেটাবেইচসমূহৰ ওপৰত লোড কমাই। এই মডেলত, ডিসপেচাৰে প্ৰথমে অনুৰোধ আগতে কৰা হৈছিল নে নাই চাব আৰু আগৰ ফলাফল উভতাই দিবলৈ চেষ্টা কৰিব, যাতে আসল এক্সিকিউশ্বন বচোৱা যায়।

ডেটাবেইচসমূহে প্ৰায়ে তাৰ পাৰ্টিশনসমূহত পঢ়া আৰু লিখাৰ একসাৰ সম্প্ৰচাৰিত হোৱাৰ পৰা লাভ কৰে। জনপ্ৰিয় আইটেমসমূহে সম্প্ৰচাৰিতত বিকৃতি ঘটাব পাৰে, যাৰ ফলত বটলনেক সৃষ্টি হয়। এখন ডেটাবেইচৰ আগত কেচ থৈ দিলে অসামান্য লোড আৰু ট্ৰাফিকৰ স্পাইকসমূহ শোষণ কৰাত সহায় কৰে।

ক্লায়েন্ট কেচিং

কেচসমূহ ক্লায়েন্ট পাশত (অ' এছ বা ব্ৰাউজাৰ), ছাৰ্ভাৰ পাশত, অথবা পৃথক কেচ স্তৰত অৱস্থিত হ’ব পাৰে।

CDN কেচিং

CDN সমূহ কেচৰ এটা প্ৰকাৰ বুলি গণ্য কৰা হয়।

ৱেব ছাৰ্ভাৰ কেচিং

Reverse proxies আৰু Varnish যেনে কেচসমূহে স্থায়ী আৰু গতিশীল বিষয়বস্তু সিধাসলাই দাঙি দিব পাৰে। ৱেব ছাৰ্ভাৰসমূহেও অনুৰোধসমূহ কেচ কৰিব পাৰে, যাতে অ্যাপ্লিকেশ্যন ছাৰ্ভাৰসমূহক যোগাযোগ নকৰাকৈ প্ৰতিক্ৰিয়া উভতাই দিব পাৰে।

ডেটাবেইচ কেচিং

আপোনাৰ ডেটাবেইচত সাধাৰণ ব্যৱহাৰৰ বাবে অপ্টিমাইজ কৰা ডিফল্ট কনফিগাৰেশ্যনত কিছু পৰিমাণৰ কেচিং থাকে। এই ছেটিংসমূহ বিশেষ ব্যৱহাৰ পেটাৰ্নৰ বাবে সলনি কৰিলে আরও অধিক পারফৰ্মেন্স বৃদ্ধি কৰিব পাৰে।

অ্যাপ্লিকেশ্যন কেচিং

Memcached আৰু Redis যেনে ইন-মেম'ৰী কেচসমূহ হৈছে আপোনাৰ অ্যাপ্লিকেশ্যন আৰু ডেটা সংৰক্ষণৰ মাজত কী-ভেল্যু ষ্ট'ৰ। ডেটা RAM-ত সংৰক্ষণ কৰা হোৱাৰ বাবে, ই সাধাৰণ ডেটাবেইচতকৈ বহুত বেছি দ্ৰুত, য’ত ডেটা ডিস্কত সংৰক্ষণ কৰা হয়। RAM-ৰ স্থান সীমিত, সেয়ে কেচ ইনভেলিডেশ্যন এলগৰিদম যেনে least recently used (LRU)) 'ঠাণ্ডা' এণ্ট্ৰিসমূহ ইনভেলিডেট কৰি 'গৰম' ডেটা RAM-ত ৰাখিবলৈ সহায় কৰে।

Redis-ত তলত দিয়া অতিৰিক্ত বৈশিষ্ট্যসমূহ আছে:

আপুনি বহু স্তৰত কেচ কৰিব পাৰে, যি দুটা সাধাৰণ শ্ৰেণীভুক্তিত পৰে: ডেটাবেইচ কুয়েরি আৰু অবজেক্টসমূহ:

সাধাৰণতে, আপুনি ফাইল-ভিত্তিক কেচিং এৰাই চলা উচিত, কাৰণ ই ক্লোনিং আৰু অটো-স্কেলিং অধিক কঠিন কৰি তোলে।

ডাটাবেছ কুৱেৰীৰ স্তৰত কেছিং

যেতিয়া আপুনি ডাটাবেছ কুৱেৰী কৰে, কুৱেৰীক এটা কী হিচাপে হেছ কৰি ফলাফলটো কেছত সংৰক্ষণ কৰক। এই পদ্ধতিটো মেয়াদ উত্তীৰ্ণ হোৱাৰ সমস্যাত ভুগে:

অবজেক্ট স্তৰত কেছিং

আপোনাৰ ডাটাটো অবজেক্ট হিচাপে চাওক, আপোনাৰ এপ্লিকেচন ক’ডৰ দৰে। আপোনাৰ এপ্লিকেচনে ডাটাবেছৰ পৰা ডাটাসেটটো ক্লাছ ইনষ্টেন্স বা ডাটা ষ্ট্ৰাকচাৰ(সমূহ)ত সংহত কৰক:

কি কেছ কৰিবলৈ পৰামৰ্শ:

কেতিয়া কেছ আপডেট কৰিব

কেছত সীমিত পৰিমাণৰ ডাটা সংৰক্ষণ কৰিব পাৰি, সেইবাবে আপোনাৰ ব্যৱহাৰ ক্ষেত্ৰত কোনটো কেছ আপডেট কৌশল উত্তম সেইটো নিৰ্ধাৰণ কৰিব লাগিব।

#### কেছ-এছাইড


Source: From cache to in-memory data grid

এপ্লিকেচনটোৱে ষ্ট’ৰেজৰ পৰা পঢ়া আৰু লিখাৰ দায়িত্ব লয়। কেছটোৱে সোজাকৈ ষ্ট’ৰেজৰ সৈতে সম্পৰ্ক নেথাকে। এপ্লিকেচনটোৱে তলত উল্লেখ কৰা কামবোৰ কৰে:

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user
Memcached সাধাৰণতে এইদৰে ব্যৱহাৰ কৰা হয়।

কেশত যোগ কৰা ডেটা পুনৰ পঢ়া তীব্ৰ গতিত হয়। কেশ-এছাইডক অলস লোডিং বুলি জনা যায়। কেৱল অনুৰোধ কৰা ডেটাহে কেশত সংৰক্ষণ কৰা হয়, যাৰ ফলত অনুৰোধ নকৰা ডেটাৰে কেশ ভৰি নাযায়।

##### অসুবিধা(সমূহ): কেশ-এছাইড

#### ৰাইট-থ্ৰু


উৎস: Scalability, availability, stability, patterns

এপ্লিকেচনে কেশক মুখ্য ডেটা ষ্ট’ৰ হিচাপে ব্যৱহাৰ কৰে, ইয়াত ডেটা পঢ়া আৰু লিখাৰ কাম কৰে, আৰু কেশে ডেটাবেছত পঢ়া আৰু লিখাৰ দায়িত্ব লয়:

এপ্লিকেচন ক’ড:

set_user(12345, {"foo":"bar"})

কেশ ক'ড:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)

Write-through এটা ধীৰ গতিৰ সামগ্ৰিক কাৰ্যপদ্ধতি, লিখা কাৰ্যপদ্ধতিৰ বাবে, কিন্তু মাত্ৰ লিখা হোৱা ডেটা পঢ়াৰ পিছৰ কাৰ্যপদ্ধতি তীব্ৰ। ব্যৱহাৰকাৰীসকলে সাধাৰণতে ডেটা আপডেট কৰাৰ সময়ত অধিক বিঢ়তিৰ সহনশীল, ডেটা পঢ়াৰ সময়তকৈ। ক্যাশত থকা ডেটা পুৰণি নহয়।

##### অপৰিসীম(s): write through

#### Write-behind (write-back)


উৎস: Scalability, availability, stability, patterns

Write-behindত, এপ্লিকেশনে তলত দিয়া কামবোৰ কৰে:

##### অপৰিসীম(s): write-behind

#### Refresh-ahead


উৎস: From cache to in-memory data grid

আপুনি ক্যাশটো কনফিগাৰ কৰিব পাৰে যাতে যিকোনো নতুনকৈ এক্সেছ কৰা ক্যাশ এণ্ট্রি তাৰ মেয়াদ শেষ হোৱাৰ আগতে স্বয়ংক্ৰিয়ভাৱে ৰিফ্ৰেশ হয়।

Refresh-aheadত latency কম হ’ব পাৰে read-throughতকৈ, যদি ক্যাশে ঠিককৈ অনুমান কৰিব পাৰে যে কোন বস্তু আগলৈ প্ৰয়োজন হ’ব।

##### অপৰিসীম(s): refresh-ahead

অসুবিধা(সমূহ): কেশ

উৎস(সমূহ) আৰু অধিক পঢ়া

অসময়তাবাদ


উৎস: স্কেলৰ বাবে ছিষ্টেম আৰ্কিটেক্টিংৰ পৰিচয়

অসময়তাবাদী workflow-এ মূল্যবান অপাৰেশ্যনসমূহৰ অনুৰোধ সময় কমাবলৈ সহায় কৰে, যিবোৰ সাধাৰণতে ইন-লাইনত কৰা হ’লেহেঁতেন। এইবোৰে আগতীয়াকৈ সময়-খৰচী কাম আদায় কৰাৰ দ্বাৰাও সহায় কৰিব পাৰে, যেনে সময় সময়ত ডেটা aggregat কৰা।

মেছেজ কিউসমূহ

মেছেজ কিউসমূহে মেছেজ গ্ৰহণ, সংৰক্ষণ আৰু বিতৰণ কৰে। যদি এটা অপাৰেশ্যন ইন-লাইনত কৰা বাবে ধীৰ হয়, তেন্তে নিম্নলিখিত workflow-ৰ সৈতে মেছেজ কিউ ব্যৱহাৰ কৰিব পাৰে:

ব্যৱহাৰকাৰী blocked নহয় আৰু চাকৰি background-ত সম্পাদিত হয়। এই সময়ত, client-এ optionally অলপ processing কৰিব পাৰে যাতে কাম শেষ হোৱাৰ অনুভূতি হয়। উদাহৰণস্বৰূপে, এটা tweet post কৰিলে, tweet-টো তৎক্ষণাত timeline-ত দেখুওৱা হ’ব পাৰে, কিন্তু সকলো follower-লৈ পৌঁছিবলৈ অলপ সময় লাগিব পাৰে।

Redis এটা সহজ মেছেজ broker হিচাপে উপযোগী, কিন্তু মেছেজ হেৰাই যাব পাৰে।

RabbitMQ জনপ্ৰিয়, কিন্তু 'AMQP' প্ৰ’টোকল অনুসৰণ কৰিব আৰু নিজৰ node-সমূহ পৰিচালনা কৰিব লাগিব। Amazon SQS হোষ্ট কৰা হৈছে কিন্তু ইয়াত উচ্চ বিলম্বতা থাকিব পাৰে আৰু বাৰ্তা দুবাৰ প্ৰেৰণ হোৱাৰ সম্ভাৱনা আছে।

Task queues

Task queues-এ কাৰ্য আৰু তাৰ লগত সংযুক্ত তথ্য গ্ৰহণ কৰে, সেইবোৰ চলায়, আৰু তাৰ ফলাফল প্ৰেৰণ কৰে। এইবোৰে সময় নিৰ্ধাৰণৰ সমৰ্থন কৰে আৰু পটভূমিত পৰিসংখ্যা-ভিত্তিক কাম চলাবলৈ ব্যৱহাৰ কৰিব পৰা যায়।

Celery-এ সময় নিৰ্ধাৰণৰ সমৰ্থন আছে আৰু প্ৰাথমিকভাৱে Python-ৰ সমৰ্থন আছে।

Back pressure

যদি queues-ৰ আকাৰ উল্লেখযোগ্যভাৱে বৃদ্ধি পায়, তেন্তে queue-ৰ আকাৰ মেম'ৰিৰ তুলনাত বেছি হ'ব পাৰে, যাৰ ফলত cache misses, disk reads, আৰু অধিক ধীৰ গতিৰ কাৰ্যক্ষমতা দেখা যায়। Back pressure-এ queue-ৰ আকাৰ সীমিত কৰি উচ্চ throughput ৰেট আৰু ইতিমধ্যে queue-ত থকা কামৰ বাবে ভাল প্ৰতিক্ৰিয়া সময় বজাই ৰাখিবলৈ সহায় কৰে। Queue পূৰ্ণ হৈ গ'লে, ক্লায়েন্টে server busy বা HTTP 503 status code পায় আৰু পাছত পুনৰ চেষ্টা কৰিবলৈ অনুৰোধ কৰা হয়। ক্লায়েন্টে পিছত অনুৰোধ পুনৰ চেষ্টা কৰিব পাৰে, সম্ভৱত exponential backoff-ৰ সৈতে।

Disadvantage(s): asynchronism

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

যোগাযোগ


উৎস: OSI 7 স্তৰ মডেল

Hypertext transfer protocol (HTTP)

HTTP হৈছে ক্লায়েন্ট আৰু ছাৰ্ভাৰৰ মাজত তথ্য সংহতি আৰু প্ৰেৰণৰ এটা পদ্ধতি। এইটো এটা অনুৰোধ/প্ৰতিক্ৰিয়া প্ৰ'ট'কল: ক্লায়েন্টে অনুৰোধ পাঠায় আৰু ছাৰ্ভাৰে সংশ্লিষ্ট বিষয়বস্তু আৰু অনুৰোধৰ সম্পূৰ্ণতাৰ অৱস্থাৰ তথ্যৰ সৈতে প্ৰতিক্ৰিয়া প্ৰেৰণ কৰে। HTTP স্ব-নিয়ন্ত্ৰিত, অনুৰোধ আৰু প্ৰতিক্ৰিয়া বহু মধ্যস্থ ৰাউটাৰ আৰু ছাৰ্ভাৰৰ মাজেৰে যাব পাৰে, যিবোৰে load balancing, caching, encryption, আৰু compression কৰে।

এটা সাধাৰণ HTTP অনুৰোধত এটা verb (method) আৰু এটা resource (endpoint) থাকে। তলত সাধাৰণ HTTP verb-সমূহ দিয়া হৈছে:

| Verb | বিৱৰণ | Idempotent* | Safe | Cacheable |

| GET | এটা ৰিছৰ্চ পঢ়ে | হয় | হয় | হয় | | POST | এটা ৰিছৰ্চ সৃষ্টি কৰে অথবা ডাটা ব্যৱহাৰ কৰি প্ৰক্ৰিয়া আৰম্ভ কৰে | নহয় | নহয় | হয় যদি প্ৰতিক্ৰিয়াত সতেজতাৰ তথ্য থাকে | | PUT | এটা ৰিছৰ্চ সৃষ্টি কৰে বা প্ৰতিস্থাপন কৰে | হয় | নহয় | নহয় | | PATCH | এটা ৰিছৰ্চ আংশিকভাৱে আপডেট কৰে | নহয় | নহয় | হয় যদি প্ৰতিক্ৰিয়াত সতেজতাৰ তথ্য থাকে | | DELETE | এটা ৰিছৰ্চ ডিলিট কৰে | হয় | নহয় | নহয় |

বহুবাৰ কল কৰিব পাৰি, ফলাফলত কোনো পাৰ্থক্য নহয়।

HTTP এটা এপ্লিকেশ্বন লেয়াৰ প্ৰ'ট'কল, যি নিম্ন-স্তৰৰ প্ৰ'ট'কল যেনে TCP আৰু UDP-ৰ ওপৰত নিৰ্ভৰ কৰে।

#### উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ: HTTP

Transmission control protocol (TCP)


উৎস: কিদৰে মাল্টিপ্লেয়াৰ গেম বনাব

TCP হৈছে এটা সংযোগ-ভিত্তিক প্ৰ'ট'কল IP নেটৱৰ্ক-ৰ ওপৰত। সংযোগ স্থাপন আৰু সমাপ্তি handshake-ৰ দ্বাৰা হয়। সকলো পেকেট মূল অনুক্ৰম আৰু বিনা বিকৃতিৰ সৈতে গন্তব্যলৈ যাবলৈ নিশ্চিত কৰা হয়:

যদি প্ৰেৰণকাৰীয়ে সঠিক প্ৰতিক্ৰিয়া লাভ নকৰে, তেতিয়া পেকেট পুনৰ প্ৰেৰণ কৰিব। বহু বাৰ টাইমআউট হ’লে, সংযোগ বন্ধ হৈ যায়। TCP-ত flow control) আৰু congestion control থাকে। এই নিশ্চয়তাসমূহে বিলম্ব ঘটায় আৰু সাধাৰণতে UDP-তকৈ কম দক্ষ প্ৰেৰণ হয়।

উচ্চ throughput নিশ্চিত কৰিবলৈ, ৱেব ছাৰ্ভাৰে বহুল TCP সংযোগ খোলা ৰাখিব পাৰে, যাৰ ফলত উচ্চ মেম'ৰি ব্যৱহাৰ হয়। ৱেব ছাৰ্ভাৰ থ্ৰেড আৰু উদাহৰণস্বৰূপে memcached ছাৰ্ভাৰৰ মাজত বহু সংযোগ খোলা ৰাখা ব্যয়বহুল হব পাৰে। Connection pooling সহায় কৰিব পাৰে, লগতে UDP-লৈ switch কৰাৰ চিন্তা কৰিব পাৰি।

TCP উপযোগী যেতিয়া উচ্চ reliability প্ৰয়োজন, কিন্তু সময় সংবেদনশীলতা কম। কিছুমান উদাহৰণ হৈছে ৱেব ছাৰ্ভাৰ, ডাটাবেছ তথ্য, SMTP, FTP, আৰু SSH।

UDP-ৰ পৰিৱৰ্তে TCP ব্যৱহাৰ কৰক, যেতিয়া:

ইউজাৰ ডাটাগ্ৰাম প্ৰ'ট'কল (UDP)


উৎস: মাল্টি-প্লেয়াৰ গেম কেনেকৈ বনাব

UDP সংযোগহীন। ডাটাগ্ৰাম (পেকেটৰ সদৃশ) কেৱল ডাটাগ্ৰাম স্তৰত গ্যারাণ্টি কৰা হয়। ডাটাগ্ৰামসমূহ গন্তব্যস্থানত অশৃঙ্খলভাৱে বা একেবাৰে নাও পোৱাৰ সম্ভাৱনা থাকে। UDP-ত সংকুলন নিয়ন্ত্ৰণৰ সুবিধা নাই। TCP-ৰ গ্যারাণ্টি নথকা বাবে, UDP সাধাৰণতে অধিক কাৰ্যকৰী।

UDP-এ সম্প্রচাৰ কৰিব পাৰে, অৰ্থাৎ ডাটাগ্ৰামসমূহ উপ-নেটৰ সকলো ডিভাইচলৈ পঠিয়াব পাৰে। ই DHCP-ৰ ক্ষেত্ৰত সহায়ক, কাৰণ ক্লায়েন্টে এতিয়াও IP ঠিকনা লাভ কৰা নাই, ফলত IP ঠিকনা নোহোৱাকৈ TCP-এ ষ্ট্ৰীম কৰিব নোৱাৰে।

UDP কম বিশ্বাসযোগ্য, কিন্তু VoIP, ভিডিঅ' চেট, ষ্ট্ৰীমিং, আৰু ৰিয়েলটাইম মাল্টিপ্লেয়াৰ গেমবোৰত ভাল কাম কৰে।

TCP-ৰ ওপৰত UDP ব্যৱহাৰ কৰক যেতিয়া:

#### উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ: TCP আৰু UDP

ৰিম'ট প্ৰ'চিজাৰ কল (RPC)


উৎস: Crack the system design interview

RPC-ত, ক্লায়েন্টে এটা প্ৰ'চিজাৰ এটা বেলেগ ঠিকনা স্থানত, সাধাৰণতে এটা ৰিম'ট চাৰ্ভাৰত চলায়। প্ৰ'চিজাৰটো এনে ধৰণে কোড কৰা হয় যেন ই এটা স্থানীয় প্ৰ'চিজাৰ কল, আৰু ক্লায়েন্ট প্ৰগ্ৰামৰ পৰা চাৰ্ভাৰৰ সৈতে যোগাযোগৰ বিৱৰণবোৰ গোপন থাকে। ৰিম'ট কলবোৰ সাধাৰণতে স্থানীয় কলতকৈ ধীৰ আৰু কম বিশ্বাসযোগ্য, সেয়ে RPC কলবোৰ স্থানীয় কলৰ পৰা পৃথক কৰি চিনাক্ত কৰা সহায়ক। জনপ্ৰিয় RPC ফ্ৰেমৱাৰ্কত আছে Protobuf, Thrift, আৰু Avro।

RPC এটা অনুৰোধ-প্ৰতিক্ৰিয়া প্ৰ'ট'কল:

নমুনা RPC কলসমূহ:

GET /someoperation?data=anId
POST /anotheroperation
{
  "data":"anId";
  "anotherdata": "another value"
}

RPC ব্যৱহাৰ আচৰণবোৰ উন্মোচন কৰাত কেন্দ্ৰিত। RPC সাধাৰণতে কাৰ্যক্ষমতাৰ কাৰণে ভিতৰুৱা যোগাযোগত ব্যৱহাৰ কৰা হয়, কিয়নো আপুনি নিজৰ ব্যৱহাৰ ক্ষেত্ৰবোৰত ভালকৈ মিলাব পৰা দেশীয় কলবোৰ হাতৰে তৈয়াৰ কৰিব পাৰে।

দেশীয় গ্ৰন্থাগাৰ (অর্থাৎ SDK) বাছনি কৰক যেতিয়া:

HTTP API যি REST অনুসৰণ কৰে, বেছিভাগ সময়ত ৰাজহুৱা API-ৰ বাবে ব্যৱহাৰ কৰা হয়।

#### অসুবিধা(সমূহ): RPC

প্ৰতিনিধিত্বমূলক অৱস্থা স্থানান্তৰ (REST)

REST হৈছে এটা স্থাপত্যিক শৈলী যিয়ে ক্লায়েন্ট/চাৰ্ভাৰ মডেলক বলবৎ কৰে, য’ত ক্লায়েন্টে চাৰ্ভাৰৰ দ্বাৰা পৰিচালিত একেটা সম্পদৰ ওপৰত কাৰ্য কৰে। চাৰ্ভাৰে সম্পদৰ প্ৰতিনিধিত্ব আৰু সেইবোৰক পৰিবৰ্তন অথবা নতুন প্ৰতিনিধিত্ব লাভ কৰিবলৈ ব্যৱস্থা প্ৰদান কৰে। সকলো যোগাযোগ অবস্থা-হীন আৰু কেছযোগ্য হ’ব লাগিব।

RESTful ইণ্টাৰফেছৰ চাৰিটা গুণ আছে:

REST কলৰ উদাহৰণ:

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}
REST ডাটা উন্মোচন কৰিবলৈ কেন্দ্ৰিত। ই ক্লায়েন্ট/চাৰ্ভাৰৰ মাজত সংযোগ কমাই দিয়ে আৰু সাধাৰণতে জনসাধাৰণ HTTP API-সমূহৰ বাবে ব্যৱহাৰ কৰা হয়। REST অধিক সাধাৰণ আৰু এক ৰূপত সম্পদসমূহ URIsৰ জৰিয়তে উন্মোচন কৰে, হেডাৰৰ জৰিয়তে প্ৰতিনিধিত্ব, আৰু GET, POST, PUT, DELETE, আৰু PATCH যেনে verb-সমূহৰ জৰিয়তে actionসমূহ কৰে। Stateless হোৱাৰ বাবে, REST horizontal scaling আৰু partitioning-ৰ বাবে অতি উত্তম।

#### অসুবিধা(সমূহ): REST

RPC আৰু REST কলৰ তুলনা

| কাৰ্য | RPC | REST | |---|---|---| | Signup | POST /signup | POST /persons | | Resign | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | এজন ব্যক্তিক পঢ়া | GET /readPerson?personid=1234 | GET /persons/1234 | | এজন ব্যক্তিৰ items list পঢ়া | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | এজন ব্যক্তিৰ itemsত item যোগ কৰা | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | এটা item আপডেট কৰা | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | এটা item ডিলিট কৰা | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

উৎস: Do you really know why you prefer REST over RPC

#### উৎস(সমূহ) আৰু অধিক পঢ়া: REST আৰু RPC

নিৰাপত্তা

এই অংশটো কিছু আপডেটৰ প্ৰয়োজন। অংদান কৰক বিবেচনা কৰক!

সুৰক্ষা এটা বিস্তৃত বিষয়। আপোনাৰ যথেষ্ট অভিজ্ঞতা, সুৰক্ষা ক্ষেত্ৰৰ পটভূমি, অথবা সুৰক্ষাৰ জ্ঞান আৱশ্যক হোৱা পদৰ বাবে আবেদন নকৰিলে, সম্ভৱতঃ আপোনাৰ আধাৰভূত জ্ঞানৰ বাহিৰে অধিক জানিব লাগিব নালাগে:

উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

সংযোজন

কেতিয়াবা আপোনাক 'ব্যাক-অফ-দি-এনভেল' অনুমান কৰিবলৈ কৈছ। উদাহৰণস্বৰূপে, আপোনাক ঠিক কৰিব লাগিব যে ১০০টা ছবি থাম্বনেইল ডিস্কৰ পৰা সৃষ্টি কৰিবলৈ কিমান সময় লাগিব বা এটা ডাটা গঠনত কিমান মেমৰী লাগিব। দুই শক্তিৰ তালিকা আৰু প্ৰত্যেক প্ৰগ্ৰামাৰে জানিবলগীয়া বিলম্বতা সংখ্যা সহায়ক সংজ্ঞা।

দুই শক্তিৰ তালিকা

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

#### উৎস(সমূহ) আৰু অধিক পঢ়িবলৈ

প্ৰতিটো প্ৰগ্ৰামাৰে জানিবলগীয়া লেটেন্সি সংখ্যা

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD     30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns
উপৰোক্ত সংখ্যাৰ আধাৰত কিছু সহায়ক মেট্ৰিক্স:

#### লেটেন্সি সংখ্যাসমূহ দৃশ্যায়িত

#### উৎস(সমূহ) আৰু অধিক পঢ়ক

অতিৰিক্ত ছিষ্টেম ডিজাইন ইণ্টাৰভিউ প্ৰশ্ন

সাধাৰণ ছিষ্টেম ডিজাইন ইণ্টাৰভিউ প্ৰশ্নসমূহ, প্রতিটো সমাধান কৰিবলৈ সংস্থানৰ সংযোগৰ সৈতে।

| প্ৰশ্ন | সংস্থান(সমূহ) | |---|---| | Dropbox দৰে ফাইল ছিঙ্ক সেৱা ডিজাইন কৰক | youtube.com | | Google দৰে এখন চাৰ্চ ইঞ্জিন ডিজাইন কৰক | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Google দৰে স্কেলেবল ৱেব ক্ৰ’লাৰ ডিজাইন কৰক | quora.com | | Google docs ডিজাইন কৰক | code.google.com
neil.fraser.name | | Redis দৰে কী-ভেলু ষ্ট’ৰ ডিজাইন কৰক | slideshare.net | | Memcached দৰে কেছ ছিষ্টেম ডিজাইন কৰক | slideshare.net | | Amazon ৰ দৰে ৰেকমেণ্ডেচন ছিষ্টেম ডিজাইন কৰক | hulu.com
ijcai13.org | | Bitly ৰ দৰে tinyurl ছিষ্টেম ডিজাইন কৰক | n00tc0d3r.blogspot.com | | WhatsApp দৰে চেট এপ ডিজাইন কৰক | highscalability.com | Instagram ৰ দৰে ছবি শ্বেয়াৰিং ছিষ্টেম ডিজাইন কৰক | highscalability.com
highscalability.com | | Facebook news feed ফাংশন ডিজাইন কৰক | quora.com
quora.com
slideshare.net | | Facebook timeline ফাংশন ডিজাইন কৰক | facebook.com
highscalability.com | | Facebook chat ফাংশন ডিজাইন কৰক | erlang-factory.com
facebook.com |

| ফেচবুকৰ দৰে এটা গ্ৰাফ সন্ধান ফাংশন ডিজাইন কৰক | facebook.com
facebook.com
facebook.com | | CloudFlareৰ দৰে এটা কন্টেন্ট ডেলিভাৰী নেটৱৰ্ক ডিজাইন কৰক | figshare.com | | টুইটাৰৰ দৰে এটা ট্রেণ্ডিং টপিক ব্যৱস্থা ডিজাইন কৰক | michael-noll.com
snikolov .wordpress.com | | এটা ৰেণ্ডম ID উৎপাদন ব্যৱস্থা ডিজাইন কৰক | blog.twitter.com
github.com | | এটা সময়সীমাৰ ভিতৰত শীৰ্ষ k অনুৰোধসমূহ উভতাই দিয়ক | cs.ucsb.edu
wpi.edu | | বহু ডাটা চেন্টাৰৰ পৰা ডাটা পৰিসেৱা কৰা ব্যৱস্থা ডিজাইন কৰক | highscalability.com | | অনলাইন মাল্টিপ্লেয়াৰ কাৰ্ড গেম ডিজাইন কৰক | indieflashblog.com
buildnewgames.com | | গাৰ্বেজ কালেকশ্বন ব্যৱস্থা ডিজাইন কৰক | stuffwithstuff.com
washington.edu | | এটা API ৰেট লিমিটাৰ ডিজাইন কৰক | https://stripe.com/blog/ | | স্টক এক্সচেঞ্জ (NASDAQ বা Binanceৰ দৰে) ডিজাইন কৰক | Jane Street
Golang Implementation
Go Implementation | | এটা ছিষ্টেম ডিজাইন প্ৰশ্ন যোগ কৰক | Contribute |

বাস্তৱিক বিশ্বৰ স্থাপত্যসমূহ

বাস্তৱিক বিশ্বৰ ছিষ্টেম কিদৰে ডিজাইন কৰা হয় তাৰ বিষয়ে প্ৰবন্ধসমূহ।


উৎস: Twitter timelines at scale

তলত থকা প্ৰবন্ধসমূহৰ বাবে সূক্ষ্ম বিষয়ত মন নিদিয়ক, তাৰ সলনি:

|প্ৰকাৰ | ছিষ্টেম | উল্লেখ(সমূহ) | |---|---|---| | ডাটা প্ৰসেসিং | MapReduce - Googleৰ পৰা বিতৰণ কৰা ডাটা প্ৰসেসিং | research.google.com | | ডাটা প্ৰসেসিং | Spark - Databricksৰ পৰা বিতৰণ কৰা ডাটা প্ৰসেসিং | slideshare.net | | ডাটা প্ৰসেসিং | Storm - Twitterৰ পৰা বিতৰণ কৰা ডাটা প্ৰসেসিং | slideshare.net | | | | | | ডাটা ষ্ট'ৰ | Bigtable - Googleৰ পৰা বিতৰণ কৰা কলাম-ভিত্তিক ডেটাবেইচ | harvard.edu | | ডাটা ষ্ট'ৰ | HBase - Bigtableৰ মুক্ত উৎস ৰূপ | slideshare.net | | ডাটা ষ্ট'ৰ | Cassandra - Facebookৰ পৰা বিতৰণ কৰা কলাম-ভিত্তিক ডেটাবেইচ | slideshare.net | ডাটা ষ্ট'ৰ | DynamoDB - Amazonৰ পৰা ডকুমেন্ট-ভিত্তিক ডেটাবেইচ | harvard.edu | | ডাটা ষ্ট'ৰ | MongoDB - ডকুমেন্ট-ভিত্তিক ডেটাবেইচ | slideshare.net | | ডাটা ষ্ট'ৰ | Spanner - Googleৰ পৰা বিশ্বব্যাপী বিতৰণ কৰা ডেটাবেইচ | research.google.com | | ডাটা ষ্ট'ৰ | Memcached - বিতৰিত মেম'ৰি কেছিং ব্যৱস্থা | slideshare.net | | ডাটা ষ্ট'ৰ | Redis - বিতৰিত মেম'ৰি কেছিং ব্যৱস্থা স্থায়িত্ব আৰু মানৰ ধৰণৰ সৈতে | slideshare.net | | | | | | ফাইল ছিষ্টেম | Google File System (GFS) - বিতৰিত ফাইল ছিষ্টেম | research.google.com | | ফাইল ছিষ্টেম | Hadoop File System (HDFS) - GFS ৰ মুক্ত উৎস ৰূপ | apache.org | | | | | | বিভিন্ন | Chubby - Google ৰ পৰা কম সংযুক্ত বিতৰিত ছিষ্টেমৰ বাবে লক সেৱা | research.google.com | | বিভিন্ন | Dapper - বিতৰিত ছিষ্টেমৰ ট্রেচিং অবকাঠামো | research.google.com | বিভিন্ন | Kafka - LinkedIn ৰ পৰা Pub/sub বাৰ্তা কিউ | slideshare.net | | বিভিন্ন | Zookeeper - কেন্দ্রীভূত অবকাঠামো আৰু সেৱা যি ছিংক্ৰনাইজেচন সক্ষম কৰে | slideshare.net | | | স্থাপত্য যোগ কৰক | Contribute |

কোম্পানী স্থাপত্যসমূহ

| কোম্পানী | উল্লেখ(সমূহ) | |---|---| | Amazon | Amazon স্থাপত্য | | Cinchcast | প্ৰতি দিনত ১,৫০০ ঘণ্টা অডিঅ' উৎপাদন | | DataSift | প্ৰতি ছেকেণ্ডত ১২০,০০০ টুইট ৰিয়েলটাইম ডাটা মাইনিং | | Dropbox | Dropbox কিদৰে স্কেল কৰা হৈছে | | ESPN | প্ৰতি ছেকেণ্ডত ১,০০,০০০ duh nuh nuhs চলোৱা | | Google | Google স্থাপত্য | | Instagram | ১৪ নিযুত ব্যৱহাৰকাৰী, টেৰাবাইট ফটো
Instagram কিদৰে চলি থাকে | | Justin.tv | Justin.tv ৰ লাইভ ভিডিঅ' সম্প্রচাৰ স্থাপত্য | | Facebook | Facebook ত memcached স্কেলিং
TAO: Facebook ৰ বিতৰিত ডাটা ষ্ট'ৰ সামাজিক গ্ৰাফৰ বাবে
Facebook ৰ ফটো সংৰক্ষণ
Facebook Live কিদৰে ৮০০,০০০ একেলগে দর্শকলৈ Streams কৰে | | Flickr | Flickr স্থাপত্য | | Mailbox | ৬ সপ্তাহত ০ ৰ পৰা ১ নিযুত ব্যৱহাৰকাৰীলৈ স্কেলিং | | Netflix | Netflix ষ্টেকৰ ৩৬০ ডিগ্ৰী দৃশ্য
Netflix: Play টিপিলে কি হয়? | | Pinterest | ০ ৰ পৰা প্ৰতি মাহত ১০ বিলিয়ন পৃষ্ঠাৰ দৰ্শনলৈ
১৮ নিযুত দর্শক, ১০x বৃদ্ধি, ১২ কৰ্মচাৰী | | Playfish | প্ৰতি মাহত ৫০ নিযুত ব্যৱহাৰকাৰী আৰু বৃদ্ধি পাইছে | | PlentyOfFish | PlentyOfFish স্থাপত্য | | Salesforce | তেওঁলোকে দিনে ১.৩ বিলিয়ন লেনদেন কেনেকৈ সজা কৰে | | Stack Overflow | Stack Overflow স্থাপত্য | | TripAdvisor | ৪০M দর্শক, ২০০M ডায়নামিক পৃষ্ঠা দৰ্শন, ৩০TB ডাটা | | Tumblr | প্ৰতি মাহত ১৫ বিলিয়ন পৃষ্ঠা দৰ্শন | | Twitter | Twitter ১০০০০ শতাংশ তীব্ৰ কৰা
Twitter কিদৰে প্ৰতি দিন ২৫০ নিযুত টুইট MySQL ৰে সংৰক্ষণ কৰে
১৫০M সক্ৰিয় ব্যৱহাৰকাৰী, ৩০০K QPS, ২২ MB/S firehose
স্কেলত টাইমলাইন
Twitter ত ডাঙৰ আৰু সৰু ডাটা
Twitter ত অপাৰেশ্যন: ১০০ নিযুত ব্যৱহাৰকাৰীৰ উৰ্ধে স্কেলিং
Twitter কিদৰে প্ৰতি ছেকেণ্ডত ৩,০০০ ছবি সজা কৰে | | Uber | Uber ৰ ৰিয়েলটাইম মাৰ্কেট প্লেটফৰ্ম কিদৰে স্কেল কৰা হয়
Uber ক ২০০০ ইঞ্জিনিয়াৰ, ১০০০ সেৱা, আৰু ৮০০০ Git ৰেপ'জিটৰি লৈ স্কেলিংৰ পাঠ | | WhatsApp | WhatsApp স্থাপত্য, Facebook এ $১৯ বিলিয়নত ক্ৰয় কৰিছিল | | YouTube | YouTube scalability
YouTube স্থাপত্য |

কোম্পানী ইঞ্জিনিয়াৰিং ব্লগসমূহ

আপোনি যিসকল কোম্পানীত সাক্ষাৎকাৰ দিব, তাত ব্যৱহৃত স্থাপত্যসমূহ।
>
আপোনি সন্মুখীন হোৱা প্ৰশ্নবোৰ একে ক্ষেত্ৰৰ পৰা আহিব পাৰে।

#### উৎস(সমূহ) আৰু অধিক পঢ়িবলগীয়া

এটা ব্লগ যোগ কৰিবলৈ বিচাৰিছে নেকি? পুনৰাবৃত্তি হোৱা কাম এৰাই, আপোনাৰ কোম্পানীৰ ব্লগ তলত দিয়া ৰেপ'ত যোগ কৰাৰ কথা ভাবিব পাৰে:

উন্নয়নৰ অধীন

এটা বিভাগ যোগ কৰিবলৈ অথবা চলি থকা এটা সম্পূৰ্ণ কৰিবলৈ আগ্ৰহী নেকি? অংশগ্ৰহণ কৰক!

ক্ৰেডিট

এই ৰেপ'ত ক্ৰেডিট আৰু উৎসসমূহ দিয়া হৈছে।

বিশেষ ধন্যবাদ:

যোগাযোগৰ তথ্য

যিকোনো সমস্যা, প্ৰশ্ন, বা মন্তব্য আলোচনা কৰিবলৈ মোক যোগাযোগ কৰিবলৈ স্বাধীন অনুভৱ কৰক।

মোৰ যোগাযোগ তথ্য মোৰ GitHub পৃষ্ঠাত পাব।

লাইচেঞ্চ

মই এই ৰেপ'জিট'ৰীত থকা ক'ড আৰু উৎসসমূহ আপোনালোকলৈ এখন মুক্ত উৎস লাইচেঞ্চৰ অধীনত প্ৰদান কৰিছোঁ। এইটো মোৰ ব্যক্তিগত ৰেপ'জিট'ৰি হোৱাৰ বাবে, আপোনালোকক মোৰ ক'ড আৰু উৎসসমূহৰ লাইচেঞ্চ মোৰ পৰা, মোৰ নিয়োগকর্তা (Facebook)ৰ পৰা নহয়।

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

http://creativecommons.org/licenses/by/4.0/

--- Tranlated By Open Ai Tx | Last indexed: 2025-08-09 ---

Original README: View on GitHub

Translated by OpenAiTx | Last updated: 2025-09-16