diff --git a/README.md b/README.md index d2f3735..7f5f0c4 100644 --- a/README.md +++ b/README.md @@ -14,69 +14,44 @@ ### সূচিপত্র -**System Design and Architecture** - - [Section 1: System Design](#section-1-system-design) -- [Section 3: Client Server Architecture](#section-3-client-server-architecture) -- [Section 15: Stateful and Stateless Architecture](#section-15-stateful-and-stateless-architecture) -- [Section 14: Authentication and Authorization](#section-14-authentication-and-authorization) -- [Section 29: Single Sign-On](#section-29-single-sign-on) -- [Section 35: Serverless Architecture] (চলমান) - -**Data Management** - - [Section 2: Database Engineering](#section-2-database-engineering) -- [Section 19: Database Sharding](#section-19-database-sharding) -- [Section 20: Database Replication](#section-20-database-replication) -- [Section 21: Caching](#section-21-caching) -- [Section 30: Elasticsearch](#section-30-elasticsearch) -- [Section 31: Bloom Filter](#section-31-bloom-filter) - -**Computer Network Concepts** - +- [Section 3: Client Server Architecture](#section-3-client-server-architecture) +- [Section 4: Reliability](#section-4-reliability) +- [Section 5: Performance Metrics](#section-5-performance-metrics) +- [Section 6: Distributed System](#section-6-distributed-system) - [Section 7: Domain Name System](#section-7-domain-name-system) - [Section 8: Transmission Control Protocol](#section-8-transmission-control-protocol) - [Section 9: User Datagram Protocol](#section-9-user-datagram-protocol) - [Section 10: HTTP and HTTPS](#section-10-http-and-https) -- [Section 34: How OAuth2 works](#section-34-how-oauth2-works) - -**Networking Techniques** - -- [Section 16: Proxy](#section-16-proxy) -- [Section 17: REST API](#section-17-rest-api) -- [Section 23: Rate Limiter](#section-23-rate-limiter) -- [Section 26: Polling and Streaming](#section-26-polling-and-streaming) -- [Section 32: Load Balancing Algorithms] (চলমান) -- [Section 33: How Live Streaming works] (চলমান) - -**Reliability and Performance** - -- [Section 4: Reliability](#section-4-reliability) -- [Section 5: Performance Metrics](#section-5-performance-metrics) -- [Section 11: High Concurrency Control](#section-11-high-concurrency-control) -- [Section 36: High Availability best practices by Netflix](#section-36-high-availability-best-practices-by-netflix) - -**Scalability** - -- [Section 18: Scalability](#section-18-scalability) - -**Distributed System** - -- [Section 6: Distributed System](#section-6-distributed-system) -- [Section 22: Content Delivery Network](#section-22-content-delivery-network) -- [Section 24: CAP Theorem](#section-24-cap-theorem) -- [Section 25: Consistent Hashing] (চলমান) -- [Section 27: Message Queue](#section-27-message-queue) -- [Section 28: rpc, gRpc] (চলমান) - -**Estimation and Planning** - -- [Section 12: Functional and Non Functional Requirements](#section-12-functional-and-non-functional-requirements) -- [Section 13: Back Of the Envelope Estimation](#section-13-back-of-the-envelope-estimation) - -**Resources** - -- [Section 37: Resources](#section-37-resources) +- [Section 11: What will happen when you type "https://www.google.com" in your browser?] (চলমান) +- [Section 12: High Concurrency Control](#section-12-high-concurrency-control) +- [Section 13: Functional and Non Functional Requirements](#section-13-functional-and-non-functional-requirements) +- [Section 14: Back Of the Envelope Estimation](#section-14-back-of-the-envelope-estimation) +- [Section 15: Authentication and Authorization](#section-15-authentication-and-authorization) +- [Section 16: Stateful and Stateless Architecture](#section-16-stateful-and-stateless-architecture) +- [Section 17: Proxy](#section-17-proxy) +- [Section 18: REST API](#section-18-rest-api) +- [Section 19: Scalability](#section-19-scalability) +- [Section 20: Database Sharding](#section-20-database-sharding) +- [Section 21: Database Replication](#section-21-database-replication) +- [Section 22: Caching](#section-22-caching) +- [Section 23: Content Delivery Network](#section-23-content-delivery-network) +- [Section 24: Rate Limiter](#section-24-rate-limiter) +- [Section 25: CAP Theorem](#section-25-cap-theorem) +- [Section 26: Consistent Hashing] (চলমান) +- [Section 27: Polling and Streaming](#section-27-polling-and-streaming) +- [Section 28: Message Queue](#section-28-message-queue) +- [Section 29: rpc, gRpc] (চলমান) +- [Section 30: Single Sign-On](#section-30-single-sign-on) +- [Section 31: Elasticsearch](#section-31-elasticsearch) +- [Section 32: Bloom Filter](#section-32-bloom-filter) +- [Section 33: Load Balancing Algorithms] (চলমান) +- [Section 34: How Live Streaming works] (চলমান) +- [Section 35: How OAuth2 works](#section-35-how-oauth2-works) +- [Section 36: Serverless Architecture] (চলমান) +- [Section 37: High Availability best practices by Netflix](#section-37-high-availability-best-practices-by-netflix) +- [Section 38: Resources](#section-38-resources) ## Section 1: System Design @@ -216,13 +191,13 @@ HTTPS অর্থাৎ Hyper Text Transfer Protocol Secure, এটি নি 🔗 [**আরও পড়ুন: এইচটিটিপি এবং এইচটিটিপি'এস**](./sections/http-and-https/README.md) -## Section 11: High Concurrency Control +## Section 12: High Concurrency Control High Concurrency মানে হচ্ছে, যখন একাধিক user কিংবা একাধিক process একই সময়/একই মুহূর্তে একটি নির্দিষ্ট রিসোর্স কিংবা একটি নির্দিষ্ট ডাটা modify করতে যায়। এর দ্বারা অনেক সমস্যা সৃষ্টি হতে পারে, যার মধ্যে সবচেয়ে গুরুত্বপূর্ণ সমস্যা হচ্ছে Data Inconsistency। (চলমান) -## Section 12: Functional and Non Functional Requirements +## Section 13: Functional and Non Functional Requirements ### Functional Requirements @@ -247,13 +222,13 @@ High Concurrency মানে হচ্ছে, যখন একাধিক user প্রতিটা হচ্ছে এক একটি Non Functional Requirement। -## Section 13: Back Of the Envelope Estimation +## Section 14: Back Of the Envelope Estimation এটি একটি টেকনিক যা আমাদেরকে সিস্টেম ডিজাইন এর Load Balancer, CDN ইত্যাদি ব্যবহার করবো কি না তার আনুমানিক ধারনা হিসাব করে বলে দিতে পারে। 🔗 [**আরও পড়ুন: ব্যাক অফ দা এনভেলপ এস্টিমেশন**](./sections/back-of-the-envelop-estimation/README.md) -## Section 14: Authentication and Authorization +## Section 15: Authentication and Authorization একটি secured সিস্টেম design করতে হলে Authentication এবং Authorization জানা অত্যন্ত গুরুত্বপূর্ণ। Authentication মূলত identity verify করাকে বুজায়। আমরা যখন কোনো সিস্টেমে গিয়ে ইমেইল এবং পাসওয়ার্ড দিয়ে লগইন করার চেষ্টা করি, সেই ইমেইল আর পাসওয়ার্ড ভেরিফাই করে হচ্ছে Authentication। @@ -261,7 +236,7 @@ Authorization হলো কোনো নির্দিষ্ট রিসোর 🔗 [**আরও পড়ুন: অথেনটিকেশন এবং অথরিজাশন**](./sections/authentication-and-authorization/README.md) -## Section 15: Stateful and Stateless Architecture +## Section 16: Stateful and Stateless Architecture ### Stateful @@ -277,7 +252,7 @@ HTTP সবসময় Stateless Architecture, কারণ কোনো protected 🔗 [**আরও পড়ুন: স্টেটলেস-স্টেটফুল আর্কিটেকচার**](./sections/stateless-stateful-architecture/README.md) -## Section 16: Proxy +## Section 17: Proxy ক্লায়েন্ট যখন সার্ভারকে রিকুয়েস্ট পাঠানোর সময় সরাসরি সার্ভারকে রিকুয়েস্ট না করে অন্য একটি সার্ভাররের মাধ্যমে রিকুয়েস্ট করলে, সেই প্রসেস হচ্ছে প্রক্সি এবং যে সার্ভার দিয়ে রিকুয়েস্ট করবে সেটা হচ্ছে প্রক্সি সার্ভার। @@ -285,7 +260,7 @@ HTTP সবসময় Stateless Architecture, কারণ কোনো protected 🔗 [**আরও পড়ুন: প্রক্সি**](./sections/proxy/README.md) -## Section 17: REST Api +## Section 18: REST Api REST Api জানার পূর্বে আমাদের বুঝতে হবে রেস্ট(REST) মানে কি, REST মানে হল Representational State Transfer যার মানে দাড়ায় এটি একটি আর্কিটেকচারাল স্টাইল যা ব্যবহার করা হয় স্টেট ট্রান্সফার এর জন্য। এখন REST Api হল, এক প্রকারের এপিআই কনভেনশন যা ব্যবহার করা হয় দুটি এন্ড(যেমনঃ ক্লায়েন্ট এবং সার্ভার) এর মধ্যে স্টেট ট্রান্সফার করাকে নিশ্চিত করার জন্য। @@ -293,7 +268,7 @@ REST Api জানার পূর্বে আমাদের বুঝতে 🔗 [**আরও পড়ুন: রেস্ট এপিআই**](./sections/rest-api/README.md) -## Section 18: Scalability +## Section 19: Scalability স্কেলেবিলিটি সাধারণত সিস্টেমের ক্ষমতাকে বুঝায় যখন সিস্টেমে ট্রাফিকের পরিমাণ বাড়তে থাকে। উদাহরণ বলা যেতে পারে, একটি ওয়েবসাইটের ডাটাবেসে এখন একটি নির্দিষ্ট পরিমাণ রিকুয়েস্ট করা হচ্ছে কিন্তু আজ থেকে ৫ মাস পর রিকুয়েস্ট ২ গুণ হয়ে গেল তার ঠিক আরও ৫ মাস পর রিকুয়েস্ট ৪ গুণ হয়ে গেল, একটা সময় দেখা যেতে পারে ডাটাবেস সার্ভার এত পরিমাণ রিকুয়েস্ট লোড নিতে পারছে না, এই সমস্যার সমাধানের জন্য স্কেল করাকে স্কেলেবিলিটি বলে। @@ -301,7 +276,7 @@ REST Api জানার পূর্বে আমাদের বুঝতে 🔗 [**আরও পড়ুন: স্কেলেবিলিটি**](./sections/scalability/README.md) -## Section 19: Database Sharding +## Section 20: Database Sharding Database Sharding হল টেবিল থেকে ডেটা পৃথক করা। উদাহরণ বলা যায়, ডাটাবেসের ডেটা/row যদি বাড়তে থাকে এবং এত পরিমাণ ডেটা/row বেড়ে গেল যার ফলে ডাটাবেস টেবিলে আর স্টোর করা যায় না তখন আমরা ডেটাগুলোকে মূল টেবিল থেকে পৃথক করে অন্যান্য shard টেবিলে distribute করে রাখি সেটাই Database Sharding। একাধিক সার্ভার এই ডিস্ট্রিবিউশন হবে। @@ -311,7 +286,7 @@ Database Sharding হল টেবিল থেকে ডেটা পৃথক 🔗 [**আরও পড়ুন: ডেটাবেস সাৰ্ডিং**](./sections/database-sharding/README.md) -## Section 20: Database Replication +## Section 21: Database Replication Database Replication এক প্রকারের Strategy, যেখানে একটি Master Database এবং একটি কিংবা একাধিক Slave Database থাকবে। Master Database এর মধ্যে Insert, Delete এবং Update এর কাজ হবে এবং Slave Database মধ্যে Master Database এর ডেটাগুলোর Copy থাকবে এবং তার মধ্যে শুধু Read Operation হবে। @@ -323,7 +298,7 @@ Database Replication, SQL এবং NoSQL দুটি ডেটাবেসে 🔗 [**আরও পড়ুন: ডেটাবেস রেপ্লিকেশন**](./sections/database-replication/README.md) -## Section 21: Caching +## Section 22: Caching Caching একটি কৌশল যা দ্বারা কোন Expensive Response'কে কোনো মেমোরিতে রাখা হয়, যাতে বার বার আসা সেই রেস্পন্সের রিকোয়েস্ট কে দ্রুত রেসপন্সটি দিতে পারি। মূল সার্ভারে (যেমন ডাটাবেস) হিট করার পরিবর্তে ক্যাশিং সার্ভারে রিকোয়েস্ট করবে। এতে করে যে সুবিধাটুকু হবে, @@ -337,7 +312,7 @@ Caching একটি কৌশল যা দ্বারা কোন Expensive 🔗 [**আরও পড়ুন: ক্যাশিং**](./sections/caching/README.md) -## Section 22: Content Delivery Network +## Section 23: Content Delivery Network Content Delivery Network অথবা CDN, এটি একটি সিস্টেম যেখানে একাধিক সার্ভার আমাদের ভৌগোলিক এর আসেপাশে থাকে, যাতে আমরা খুব দ্রুত কন্টেন্ট পেতে পারি। কন্টেন্টটি হতে পারে JS, CSS, Images কিংবা Videos। @@ -352,7 +327,7 @@ Content Delivery Network অথবা CDN, এটি একটি সিস্ 🔗 [**আরও পড়ুন: কনটেন্ট ডেলিভারি নেটওয়ার্ক**](./sections/cdn/README.md) -## Section 23: Rate Limiter +## Section 24: Rate Limiter Rate Limiter একটি প্রসেস, যেখানে ক্লায়েন্ট থেকে আসা রিকোয়েস্ট সার্ভারে যাওয়ার পূর্বে রিকোয়েস্টটি কন্ট্রোল করা হয়। একটি নির্দিষ্ট সময়ের মধ্যে একটি নির্দিষ্ট পরিমাণ রিকোয়েস্ট Rate Limiter এর মাধ্যমে সার্ভার রিকোয়েস্ট গ্রহণ করে থাকে। নির্দিষ্ট পরিমানের চেয়ে রিকোয়েস্ট বেশি হয়ে গেলে Rate Limiter রিকোয়েস্টগুলোকে block করে ফেলে, যার ফলে রিকোয়েস্টগুলো আর সার্ভারে যেতে পারে না। @@ -366,7 +341,7 @@ Rate Limiter একটি প্রসেস, যেখানে ক্লায় 🔗 [**আরও পড়ুন: রেইট লিমিটার**](./sections/rate-limiter/README.md) -## Section 24: CAP Theorem +## Section 25: CAP Theorem এটি একটি কনসেপ্ট বা থিওরি যা দ্বারা বুজা যায়, একটি Distributed System এ উল্লিখিত তিনটি প্রোপার্টি থেকে দুইটি প্রোপার্টি সবসময় মেনে চলবে। @@ -382,7 +357,7 @@ Partition Tolerance হচ্ছে একাধিক নোড একে অ 🔗 [**আরও পড়ুন: ক্যাপ থিওরাম**](./sections/cap-theorem/README.md) -## Section 26: Polling and Streaming +## Section 27: Polling and Streaming Polling মানে হচ্ছে client regular interval এ server কে বার বার ডেটার জন্য রিকোয়েস্ট করবে। যেমন, ক্লায়েন্ট প্রতি ৫ সেকেন্ড পর পর সার্ভার কে রিকোয়েস্ট করবে আর সার্ভার তার রেসপন্স দিবে। @@ -402,7 +377,7 @@ Streaming কিংবা Pushing এ সার্ভার এবং ক্ল 🔗 [**আরও পড়ুন: পোলিং স্ট্রিমিং**](./sections/polling-and-streaming/README.md) -## Section 27: Message Queue +## Section 28: Message Queue এটি একটি প্রসেস যেখানে এক বা একাধিক Producer থাকবে, যাদের কাজ হচ্ছে Message(এখানে message মানে রিকোয়েস্ট) Queue এর মধ্যে send করা এবং queue সেই রিকোয়েস্টগুলোকে প্রসেস করে বিভিন্ন consumer এর কাছে পাঠিয়ে দেয়। @@ -427,7 +402,7 @@ Message Queue প্রতিটা Task কে Asynchronously প্রসে 🔗 [**আরও পড়ুন: মেসেজ কিউ**](./sections/message-queue/README.md) -## Section 29: Single Sign-On +## Section 30: Single Sign-On Single Sign-On কিংবা SSO হল একটি Authentication Mechanism। যা user কে একাধিক প্লাটফর্ম (গুগল, ফেইসবুক, টুইটার) দিয়ে Authenticate করে দেয়, একটি নির্দিষ্ট credential মাধ্যমে। @@ -437,13 +412,13 @@ Single Sign-On কিংবা SSO হল একটি Authentication Mechanism (বিস্তারিত চলমান) -## Section 30: Elasticsearch +## Section 31: Elasticsearch এটি একটি NoSQL ভিত্তিক ডেটাবেস। মূলত এটিকে Distributed Search এবং Aggregation Engine হিসেবে ব্যবহার করা হয়। Elasticsearch এর ভিতর structured এবং unstructured data স্টোর করে রাখা যায়। 🔗 [**আরও পড়ুন: ইলাস্টিকসার্চ**](./sections/elasticsearch/README.md) -## Section 31: Bloom Filter +## Section 32: Bloom Filter Bloom Filter একটি Probabilistic Data Structure। Hashing টেকনিক ব্যবহার করে এখানে ডেটা insert করা হয়। এটি খুবই Faster এবং মেমোরি Efficient। @@ -476,7 +451,7 @@ Bloom Filter Data Structure এ Hash function ব্যবহার করে 🔗 [**আরও পড়ুন: ব্লুম ফিল্টার**](./sections/bloom-filter/README.md) -## Section 34: How OAuth2 works +## Section 35: How OAuth2 works OAuth2 হল এক প্রকারের Authorization Grant Technique। এটি Google, Facebook এর মত ওয়েবসাইট থেকে নির্দিষ্ট information আনতে পারে কোনো প্রকারের password এবং অন্যান্য sensitive information ছাড়া। এই নির্দিষ্ট information এ একটি Access Token থাকে যা দ্বারা আমরা নির্দিষ্ট রিসোর্স(হতে পারে কোনো ওয়েবসাইট এ Login) ব্যবহার করতে পারবো। @@ -494,7 +469,7 @@ OAuth2 হল এক প্রকারের Authorization Grant Technique। oauth2

-## Section 36: High Availability best practices by Netflix +## Section 37: High Availability best practices by Netflix Netflix High Availability নিশ্চিত করার জন্য কিছু টিপস শেয়ার করেছিল(যেগুলো এরা নিজে follow করে থাকে) যা আমাদের অনেক সিস্টেমের কাজে লাগবে, @@ -510,7 +485,7 @@ Netflix High Availability নিশ্চিত করার জন্য কি Original Post: https://netflixtechblog.medium.com/tips-for-high-availability-be0472f2599c -## Section 37: Resources +## Section 38: Resources - System Design Primer by Donne Martin (free) - Designing Data Intensive Applications (paid) diff --git a/sections/database/README.md b/sections/database/README.md index c8568b4..9593a20 100644 --- a/sections/database/README.md +++ b/sections/database/README.md @@ -93,7 +93,7 @@ Database Sharding হল টেবিল থেকে ডেটা পৃথক Connection Pool এর size randomly সেট করা যাবে না। Concurrent Users এর সংখ্যা নিয়ে চিন্তা করতে হবে। উদাহরণস্বরূপ, যদি আপনার অ্যাপ্লিকেশনে ২০০০ concurrent users থাকে, তবে সব ২০০০ ব্যবহারকারী একসঙ্গে ডেটাবেসে আঘাত করবে না। তাই কত শতাংশ ব্যবহারকারী একযোগে ডেটাবেস request করবে তা estimate করুন এবং সেই অনুযায়ী Connection Pool এর size নির্ধারণ করুন। -## Buffer Pool (InnoDB অনুসারে) +### Buffer Pool (InnoDB অনুসারে) এটি মূল মেমোরি বা RAM এর ভিতরের একটি এলাকা, যেখানে InnoDB (MySQL ইঞ্জিন) টেবিল এবং ইনডেক্স ডেটা ক্যাশ করে রাখে যখন তা access করা হয়। ডেটা সরাসরি বাফার পুল থেকে অ্যাক্সেস করার মাধ্যমে আমরা query processing এর সময়কে দ্রুততর করতে পারি। @@ -148,3 +148,8 @@ RAM যদি ৪ GB হয়? ### Hardware এবং Infrastructure আমাদের ডাটাবেস এর পারফরমেন্স ভালো করতে পারে সেজন্য আমাদের requirements অনুযায়ী Hardware এবং Infrastructure নেয়া। + +## Write/Update অপারেশন এর জন্য Performance Optimization + +- অপ্রোজনীয় কলাম ইনডেক্সিং না করা। কারণ যখন নতুন row ইন্সার্ট হবে তবে ইনডেক্স টেবিলেও রেফারেন্স ইন্সার্ট হবে যা write অপারেশন slow করে দিতে পারে। +- innodb_buffer_pool_size সেট করা। কারণ প্রতিটি write অপারেশন সরাসরি ডিস্ক এ গিয়ে স্টোর হয় না, বরং বাফার পুল এর ভিতর অবস্থান করে প্রথমে। তাই বাফার পুলের size enough থাকলে write অপারেশন fast হবে। diff --git a/sections/rest-api/README.md b/sections/rest-api/README.md index 97356b9..637569a 100644 --- a/sections/rest-api/README.md +++ b/sections/rest-api/README.md @@ -113,6 +113,12 @@ router.get("/users", (req, res) => { ? এর পরের অংশটুকু হল Query Parameters. +- Health check endpoint তৈরী করে রাখা। উদাহরণ, /health - যা বলে দিবে সার্ভিস healthy আছে কি না। + +- ISO 8601 UTC dates ব্যবহার করা। যখন আমরা Time এবং Date নিয়ে কাজ করবো তখন ISO 8601 UTC dates আকারে সার্ভার থেকে ক্লায়েন্টের কাছে পাঠিয়ে দিবো। নির্দিষ্ট time-zone এ দেখানো তা ক্লায়েন্ট সাইড এর বিষয়। + +- নির্দিষ্ট রেস্পন্সের জন্য নির্দিষ্ট Status Code ব্যবহার করা। + ## Rest API security best practices - HTTPS ব্যবহার করা। @@ -133,11 +139,11 @@ router.get("/users", (req, res) => { ### Pagination -২ রকমের pagination techniques আমাদের কাছে আছে। Offset এবং Cursor। আমাদের requirements এর উপর ভিত্তি করে আমরা pagination technique ব্যবহার করব। +২ রকমের pagination techniques আমাদের কাছে আছে। Offset এবং Cursor। আমাদের requirements এর উপর ভিত্তি করে আমরা pagination technique ব্যবহার করব। ### Data Compression -Data Compressed করলে আমরা API response এর size কমাতে পারবো। +Data Compressed করলে আমরা API response এর size কমাতে পারবো। ### Unnecessary property send to payload and response