Date: Mon, 20 Nov 2023 19:16:24 +0500
Subject: [PATCH 2/8] inintialize
---
README.md | 316 +++++++++++++++++++++++++++---------------------------
1 file changed, 158 insertions(+), 158 deletions(-)
diff --git a/README.md b/README.md
index 6393b7e..aad74d2 100644
--- a/README.md
+++ b/README.md
@@ -24,139 +24,139 @@ Whether you're preparing for a System Design Interview or you simply want to und
-- [Communication protocols](#communication-protocols)
- - [REST API vs. GraphQL](#rest-api-vs-graphql)
- - [How does gRPC work?](#how-does-grpc-work)
- - [What is a webhook?](#what-is-a-webhook)
- - [How to improve API performance?](#how-to-improve-api-performance)
- - [HTTP 1.0 -\> HTTP 1.1 -\> HTTP 2.0 -\> HTTP 3.0 (QUIC)](#http-10---http-11---http-20---http-30-quic)
- - [SOAP vs REST vs GraphQL vs RPC](#soap-vs-rest-vs-graphql-vs-rpc)
- - [Code First vs. API First](#code-first-vs-api-first)
- - [HTTP status codes](#http-status-codes)
- - [What does API gateway do?](#what-does-api-gateway-do)
- - [How do we design effective and safe APIs?](#how-do-we-design-effective-and-safe-apis)
- - [TCP/IP encapsulation](#tcpip-encapsulation)
- - [Why is Nginx called a “reverse” proxy?](#why-is-nginx-called-a-reverse-proxy)
- - [What are the common load-balancing algorithms?](#what-are-the-common-load-balancing-algorithms)
- - [URL, URI, URN - Do you know the differences?](#url-uri-urn---do-you-know-the-differences)
+- [Aloqa protokollari](#aloqa-protokollari)
+ - [REST API va GraphQL](#rest-api-va-graphql)
+ - [gRPC qanday ishlaydi?](#grpc-qanday-ishlaydi)
+ - [Webhook nima?](#webhook-nima)
+ - [API ish faoliyatini qanday yaxshilash mumkin?](#api-ish-faoliyatini-qanday-yaxshilash-mumkin)
+ - [HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)](#http-10---http-11---http-20---http-30-quic)
+ - [SOAP va REST va GraphQL va RPC](#soap-va-rest-va-graphql-va-rpc)
+ - [Code First va API First](#code-first-va-api-first)
+ - [HTTP holat kodlari](#http-holat-kodlari)
+ - [API shlyuzi nima qiladi?](#api-shlyuzi-nima-qiladi)
+ - [Qanday qilib samarali va xavfsiz API-larni loyihalashtiramiz?](#qanday-qilib-samarali-va-xavfsiz-api-larni-loyihalashtiramiz)
+ - [TCP/IP inkapsulyatsiyasi](#tcpip-inkapsulyatsiyasi)
+ - [Nima uchun Nginx "teskari" proksi-server deb ataladi?](#nima-uchun-nginx-teskari-proksi-server-deb-ataladi)
+ - [Umumiy yuklarni muvozanatlash algoritmlari qanday?](#umumiy-yuklarni-muvozanatlash-algoritmlari-qanday)
+ - [URL, URI, URN - Farqlarni bilasizmi?](#url-uri-urn---farqlarni-bilasizmi)
- [CI/CD](#cicd)
- - [CI/CD Pipeline Explained in Simple Terms](#cicd-pipeline-explained-in-simple-terms)
+ - [CI/CD quvur liniyasi oddiy so'zlar bilan tushuntirilgan](#cicd-pipeline-explained-in-simple-terms)
- [Netflix Tech Stack (CI/CD Pipeline)](#netflix-tech-stack-cicd-pipeline)
-- [Architecture patterns](#architecture-patterns)
- - [MVC, MVP, MVVM, MVVM-C, and VIPER](#mvc-mvp-mvvm-mvvm-c-and-viper)
- - [18 Key Design Patterns Every Developer Should Know](#18-key-design-patterns-every-developer-should-know)
-- [Database](#database)
- - [A nice cheat sheet of different databases in cloud services](#a-nice-cheat-sheet-of-different-databases-in-cloud-services)
- - [8 Data Structures That Power Your Databases](#8-data-structures-that-power-your-databases)
- - [How is an SQL statement executed in the database?](#how-is-an-sql-statement-executed-in-the-database)
- - [CAP theorem](#cap-theorem)
- - [Types of Memory and Storage](#types-of-memory-and-storage)
- - [Visualizing a SQL query](#visualizing-a-sql-query)
- - [SQL language](#sql-language)
-- [Cache](#cache)
- - [Data is cached everywhere](#data-is-cached-everywhere)
- - [Why is Redis so fast?](#why-is-redis-so-fast)
- - [How can Redis be used?](#how-can-redis-be-used)
- - [Top caching strategies](#top-caching-strategies)
-- [Microservice architecture](#microservice-architecture)
- - [What does a typical microservice architecture look like?](#what-does-a-typical-microservice-architecture-look-like)
- - [Microservice Best Practices](#microservice-best-practices)
- - [What tech stack is commonly used for microservices?](#what-tech-stack-is-commonly-used-for-microservices)
- - [Why is Kafka fast](#why-is-kafka-fast)
-- [Payment systems](#payment-systems)
- - [How to learn payment systems?](#how-to-learn-payment-systems)
- - [Why is the credit card called “the most profitable product in banks”? How does VISA/Mastercard make money?](#why-is-the-credit-card-called-the-most-profitable-product-in-banks-how-does-visamastercard-make-money)
- - [How does VISA work when we swipe a credit card at a merchant’s shop?](#how-does-visa-work-when-we-swipe-a-credit-card-at-a-merchants-shop)
- - [Payment Systems Around The World Series (Part 1): Unified Payments Interface (UPI) in India](#payment-systems-around-the-world-series-part-1-unified-payments-interface-upi-in-india)
+- [Arxitektura naqshlari](#architecture-patterns)
+ - [MVC, MVP, MVVM, MVVM-C va VIPER](#mvc-mvp-mvvm-mvvm-c-and-viper)
+ - [Har bir dasturchi bilishi kerak bo'lgan 18 ta asosiy dizayn naqshlari](#18-key-design-patterns-every-developer-should-know)
+- [Ma'lumotlar bazasi](#database)
+ - [Bulutli xizmatlardagi turli xil ma'lumotlar bazalarining chiroyli cheat varag'i ](#a-nice-cheat-sheet-of-different-databases-in-cloud-services)
+ - [Ma'lumotlar bazalaringizni quvvatlantiradigan 8 ta ma'lumotlar tuzilmasi](#8-data-structures-that-power-your-databases)
+ - [Ma'lumotlar bazasida SQL operatori qanday bajariladi?](#how-is-an-sql-statement-executed-in-the-database)
+ - [CAP teoremasi](#cap-theorem)
+ - [Xotira va saqlash turlari](#types-of-memory-and-storage)
+ - [SQL so'rovini vizualizatsiya qilish](#visualizing-a-sql-query)
+ - [SQL tili](#sql-language)
+- [Kesh](#cache)
+ - [Ma'lumotlar hamma joyda keshlangan](#data-is-cached-everywhere)
+ - [Nima uchun Redis juda tez?](#why-is-redis-so-fast)
+ - [Redis-dan qanday foydalanish mumkin?](#how-can-redis-be-used)
+ - [Eng yaxshi keshlash strategiyalari](#top-caching-strategies)
+- [Mikroservis arxitekturasi](#microservice-architecture)
+ - [Oddiy mikroservis arxitekturasi nimaga o'xshaydi?](#what-does-a-typical-microservice-architecture-look-like)
+ - [Mikroservisning eng yaxshi amaliyotlari](#microservice-best-practices)
+ - [Mikroservislar uchun qanday texnologik stek ishlatiladi?](#what-tech-stack-is-commonly-used-for-microservices)
+ - [Nega Kafka tez](#why-is-kafka-fast)
+- [To'lov tizimlari](#payment-systems)
+ - [To'lov tizimini qanday o'rganish mumkin?](#how-to-learn-payment-systems)
+ - [Nima uchun kredit karta "banklardagi eng daromadli mahsulot" deb ataladi? VISA/Mastercard qanday qilib pul ishlaydi?](#why-is-the-credit-card-called-the-most-profitable-product-in-banks-how-does-visamastercard-make-money)
+ - [Savdogarlar do'konida kredit kartani o'tkazganimizda VISA qanday ishlaydi?](#how-does-visa-work-when-we-swipe-a-credit-card-at-a-merchants-shop)
+ - [Dunyo bo'ylab to'lov tizimlari seriyasi (1-qism): Hindistonda yagona to'lov interfeysi (UPI)](#payment-systems-around-the-world-series-part-1-unified-payments-interface-upi-in-india)
- [DevOps](#devops)
- - [DevOps vs. SRE vs. Platform Engineering. What is the difference?](#devops-vs-sre-vs-platform-engineering-what-is-the-difference)
- - [What is k8s (Kubernetes)?](#what-is-k8s-kubernetes)
- - [Docker vs. Kubernetes. Which one should we use?](#docker-vs-kubernetes-which-one-should-we-use)
- - [How does Docker work?](#how-does-docker-work)
+ - [DevOps va SRE va platforma muhandisligi. Farqi nimada?](#devops-vs-sre-vs-platform-engineering-what-is-the-difference)
+ - [K8s (Kubernetes) nima?](#what-is-k8s-kubernetes)
+ - [Docker va Kubernetes. Qaysi birini ishlatishimiz kerak?](#docker-vs-kubernetes-which-one-should-we-use)
+ - [Docker qanday ishlaydi?](#how-does-docker-work)
- [GIT](#git)
- - [How Git Commands work](#how-git-commands-work)
- - [How does Git Work?](#how-does-git-work)
- - [Git merge vs. Git rebase](#git-merge-vs-git-rebase)
-- [Cloud Services](#cloud-services)
- - [A nice cheat sheet of different cloud services (2023 edition)](#a-nice-cheat-sheet-of-different-cloud-services-2023-edition)
- - [What is cloud native?](#what-is-cloud-native)
-- [Developer productivity tools](#developer-productivity-tools)
- - [Visualize JSON files](#visualize-json-files)
- - [Automatically turn code into architecture diagrams](#automatically-turn-code-into-architecture-diagrams)
+ - [Git buyruqlari qanday ishlaydi](#how-git-commands-work)
+ - [Git qanday ishlaydi?](#how-does-git-work)
+ - [Git merge va Git rebase](#git-merge-vs-git-rebase)
+- [Bulutli xizmatlar](#cloud-services)
+ - [Turli xil bulut xizmatlarining chiroyli cheat varag'i (2023 yil nashri)](#a-nice-cheat-sheet-of-different-cloud-services-2023-edition)
+ - [Mahalliy bulut nima?](#what-is-cloud-native)
+- [Ishlab chiquvchi mahsuldorlik vositalari](#developer-productivity-tools)
+ - [JSON fayllarini vizualizatsiya qilish](#visualize-json-files)
+ - [Kodni avtomatik ravishda arxitektura diagrammalariga aylantiring](#automatically-turn-code-into-architecture-diagrams)
- [Linux](#linux)
- - [Linux file system explained](#linux-file-system-explained)
- - [18 Most-used Linux Commands You Should Know](#18-most-used-linux-commands-you-should-know)
-- [Security](#security)
- - [How does HTTPS work?](#how-does-https-work)
- - [Oauth 2.0 Explained With Simple Terms.](#oauth-20-explained-with-simple-terms)
- - [Top 4 Forms of Authentication Mechanisms](#top-4-forms-of-authentication-mechanisms)
- - [Session, cookie, JWT, token, SSO, and OAuth 2.0 - what are they?](#session-cookie-jwt-token-sso-and-oauth-20---what-are-they)
- - [How to store passwords safely in the database and how to validate a password?](#how-to-store-passwords-safely-in-the-database-and-how-to-validate-a-password)
- - [Explaining JSON Web Token (JWT) to a 10 year old Kid](#explaining-json-web-token-jwt-to-a-10-year-old-kid)
- - [How does Google Authenticator (or other types of 2-factor authenticators) work?](#how-does-google-authenticator-or-other-types-of-2-factor-authenticators-work)
-- [Real World Case Studies](#real-world-case-studies)
- - [Netflix's Tech Stack](#netflixs-tech-stack)
- - [Twitter Architecture 2022](#twitter-architecture-2022)
- - [Evolution of Airbnb’s microservice architecture over the past 15 years](#evolution-of-airbnbs-microservice-architecture-over-the-past-15-years)
- - [Monorepo vs. Microrepo.](#monorepo-vs-microrepo)
- - [How will you design the Stack Overflow website?](#how-will-you-design-the-stack-overflow-website)
- - [Why did Amazon Prime Video monitoring move from serverless to monolithic? How can it save 90% cost?](#why-did-amazon-prime-video-monitoring-move-from-serverless-to-monolithic-how-can-it-save-90-cost)
- - [How does Disney Hotstar capture 5 Billion Emojis during a tournament?](#how-does-disney-hotstar-capture-5-billion-emojis-during-a-tournament)
- - [How Discord Stores Trillions Of Messages](#how-discord-stores-trillions-of-messages)
- - [How do video live streamings work on YouTube, TikTok live, or Twitch?](#how-do-video-live-streamings-work-on-youtube-tiktok-live-or-twitch)
+ - [Linux fayl tizimi tushuntirildi](#linux-file-system-explained)
+ - [Siz bilishingiz kerak bo'lgan 18 ta eng ko'p ishlatiladigan Linux buyruqlari](#18-most-used-linux-commands-you-should-know)
+- [Xavfsizlik](#security)
+ - [HTTPS qanday ishlaydi?](#how-does-https-work)
+ - [Oauth 2.0 oddiy shartlar bilan tushuntirilgan.](#oauth-20-explained-with-simple-terms)
+ - [Autentifikatsiya mexanizmlarining 4 ta eng yaxshi shakllari](#top-4-forms-of-authentication-mechanisms)
+ - [Sessiya, cookie, JWT, token, SSO va OAuth 2.0 - ular nima?](#session-cookie-jwt-token-sso-and-oauth-20---what-are-they)
+ - [Ma'lumotlar bazasida parollarni qanday xavfsiz saqlash va parolni qanday tekshirish mumkin?](#how-to-store-passwords-safely-in-the-database-and-how-to-validate-a-password)
+ - [10 yoshli bolaga JSON Web Token (JWT) haqida tushuntirish](#explaining-json-web-token-jwt-to-a-10-year-old-kid)
+ - [Google Authenticator (yoki 2 faktorli autentifikatsiyaning boshqa turlari) qanday ishlaydi?](#how-does-google-authenticator-or-other-types-of-2-factor-authenticators-work)
+- [Haqiqiy dunyo misollari](#real-world-case-studies)
+ - [Netflixning Tech Stacki](#netflixs-tech-stack)
+ - [Twitter arxitekturasi 2022](#twitter-architecture-2022)
+ - [Oxirgi 15 yil ichida Airbnb mikroservis arxitekturasining evolyutsiyasi](#evolution-of-airbnbs-microservice-architecture-over-the-past-15-years)
+ - [Monorepo va mikrorepo.](#monorepo-vs-microrepo)
+ - [Stack Overflow veb-saytini qanday loyihalashtirasiz?](#how-will-you-design-the-stack-overflow-website)
+ - [Nima uchun Amazon Prime Video monitoringi serversizdan monolitga o'tdi? Qanday qilib 90% xarajatlarni tejash mumkin?](#why-did-amazon-prime-video-monitoring-move-from-serverless-to-monolithic-how-can-it-save-90-cost)
+ - [Disney Hotstar turnir davomida 5 milliard kulgichni qanday suratga oladi?](#how-does-disney-hotstar-capture-5-billion-emojis-during-a-tournament)
+ - [Discord qanday qilib trillionlab xabarlarni saqlaydi](#how-discord-stores-trillions-of-messages)
+ - [YouTube, TikTok live yoki Twitch-da jonli video oqimlari qanday ishlaydi?](#how-do-video-live-streamings-work-on-youtube-tiktok-live-or-twitch)
-## Communication protocols
+## Aloqa protokollari
-Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles:
+Arxitektura uslublari amaliy dasturlash interfeysining (API) turli komponentlari bir-biri bilan qanday o'zaro ta'sir qilishini belgilaydi.Natijada, ular API-larni loyihalash va qurishda standart yondashuvni ta'minlash orqali samaradorlik, ishonchlilik va boshqa tizimlar bilan integratsiya qulayligini ta'minlaydi. Bu erda eng ko'p ishlatiladigan uslublar:
-- SOAP:
-
- Mature, comprehensive, XML-based
+- SOAP:
+
+ Yetuk, keng qamrovli, XML-ga asoslangan
- Best for enterprise applications
+ Korporativ ilovalar uchun eng yaxshi
-- RESTful:
+- RESTful:
- Popular, easy-to-implement, HTTP methods
+ Ommabop, amalga oshirish oson, HTTP usullari
- Ideal for web services
+ Veb-xizmatlar uchun ideal
-- GraphQL:
+- GraphQL:
- Query language, request specific data
+ So'rov tili, maxsus ma'lumotlarni so'rash
- Reduces network overhead, faster responses
+ Tarmoq yukini kamaytiradi, tezroq javob beradi
-- gRPC:
+- gRPC:
- Modern, high-performance, Protocol Buffers
+ Zamonaviy, yuqori samarali, protokol buferlari
- Suitable for microservices architectures
+ Mikroservislar arxitekturasi uchun javob beradi
-- WebSocket:
+- WebSocket:
- Real-time, bidirectional, persistent connections
+ Real-time, bidirectional, persistent connections
- Perfect for low-latency data exchange
+ Kam kechikishli ma'lumotlar almashinuvi uchun juda mos keladi
-- Webhook:
+- Webhook:
- Event-driven, HTTP callbacks, asynchronous
+ Voqealarga asoslangan, HTTP qo'ng'iroqlari, asinxron
- Notifies systems when events occur
+ Voqea sodir bo'lganda tizimlarni xabardor qiladi
-### REST API vs. GraphQL
+### REST API va GraphQL
-When it comes to API design, REST and GraphQL each have their own strengths and weaknesses.
+API dizayni haqida gap ketganda, REST va GraphQL har birining kuchli va zaif tomonlari bor.
-The diagram below shows a quick comparison between REST and GraphQL.
+Quyidagi diagrammada REST va GraphQL o'rtasidagi tezkor taqqoslash ko'rsatilgan.
@@ -164,108 +164,108 @@ The diagram below shows a quick comparison between REST and GraphQL.
REST
-- Uses standard HTTP methods like GET, POST, PUT, DELETE for CRUD operations.
-- Works well when you need simple, uniform interfaces between separate services/applications.
-- Caching strategies are straightforward to implement.
-- The downside is it may require multiple roundtrips to assemble related data from separate endpoints.
+- CRUD operatsiyalari uchun GET, POST, PUT, DELETE kabi standart HTTP usullaridan foydalanadi.
+- Alohida xizmatlar/ilovalar o'rtasida oddiy, bir xil interfeyslar kerak bo'lganda yaxshi ishlaydi.
+- Keshlash strategiyalarini amalga oshirish oson.
+- Salbiy tomoni shundaki, u alohida so'nggi nuqtalardan tegishli ma'lumotlarni yig'ish uchun bir nechta aylanishlarni talab qilishi mumkin.
GraphQL
-- Provides a single endpoint for clients to query for precisely the data they need.
-- Clients specify the exact fields required in nested queries, and the server returns optimized payloads containing just those fields.
-- Supports Mutations for modifying data and Subscriptions for real-time notifications.
-- Great for aggregating data from multiple sources and works well with rapidly evolving frontend requirements.
-- However, it shifts complexity to the client side and can allow abusive queries if not properly safeguarded
-- Caching strategies can be more complicated than REST.
+- Mijozlarga kerakli ma'lumotlarni aniq so'rashlari uchun yagona so'nggi nuqtani taqdim etadi.
+- Mijozlar ichki so'rovlarda talab qilinadigan aniq maydonlarni belgilaydi va server faqat shu maydonlarni o'z ichiga olgan optimallashtirilgan foydali yuklarni qaytaradi.
+- Ma'lumotlarni o'zgartirish uchun mutatsiyalarni va real vaqtda bildirishnomalar uchun obunalarni qo'llab-quvvatlaydi.
+- Bir nechta manbalardan ma'lumotlarni jamlash uchun ajoyib va tez rivojlanayotgan frontend talablari bilan yaxshi ishlaydi.
+- Biroq, u murakkablikni mijoz tomoniga o'tkazadi va agar to'g'ri himoyalanmagan bo'lsa, haqoratli so'rovlarga ruxsat berishi mumkin.
+- Keshlash strategiyalari RESTga qaraganda murakkabroq bo'lishi mumkin.
-The best choice between REST and GraphQL depends on the specific requirements of the application and development team. GraphQL is a good fit for complex or frequently changing frontend needs, while REST suits applications where simple and consistent contracts are preferred.
+REST va GraphQL o'rtasidagi eng yaxshi tanlov dastur va ishlab chiqish guruhining o'ziga xos talablariga bog'liq. GraphQL murakkab yoki tez-tez o'zgaruvchan frontend ehtiyojlari uchun juda mos keladi, REST esa oddiy va izchil shartnomalar afzal ko'rilgan ilovalarga mos keladi.
-Neither API approach is a silver bullet. Carefully evaluating requirements and tradeoffs is important to pick the right style. Both REST and GraphQL are valid options for exposing data and powering modern applications.
+Hech bir API yondashuvi kumush o'q emas. To'g'ri uslubni tanlash uchun talablar va kelishuvlarni diqqat bilan baholash muhimdir. REST va GraphQL ikkalasi ham ma'lumotlarni oshkor qilish va zamonaviy ilovalarni quvvatlantirish uchun to'g'ri tanlovdir.
-### How does gRPC work?
+### gRPC qanday ishlaydi?
-RPC (Remote Procedure Call) is called “**remote**” because it enables communications between remote services when services are deployed to different servers under microservice architecture. From the user’s point of view, it acts like a local function call.
+RPC (Remote Procedure Call) "**remote(masofaviy)**" deb nomlanadi, chunki u xizmatlar mikroservis arxitekturasi ostida turli serverlarga o'rnatilganda masofaviy xizmatlar o'rtasida aloqa o'rnatish imkonini beradi. Foydalanuvchi nuqtai nazaridan, u mahalliy funktsiya chaqiruvi kabi ishlaydi.
-The diagram below illustrates the overall data flow for **gRPC**.
+Quyidagi diagramma **gRPC** uchun umumiy ma'lumotlar oqimini ko'rsatadi.
-Step 1: A REST call is made from the client. The request body is usually in JSON format.
+1-qadam: REST qo'ng'irog'i mijozdan amalga oshiriladi. So'rovning asosiy qismi odatda JSON formatida bo'ladi.
-Steps 2 - 4: The order service (gRPC client) receives the REST call, transforms it, and makes an RPC call to the payment service. gRPC encodes the **client stub** into a binary format and sends it to the low-level transport layer.
+2-4-qadamlar: Buyurtma xizmati (gRPC mijozi) REST qo'ng'irog'ini qabul qiladi, uni o'zgartiradi va to'lov xizmatiga RPC qo'ng'irog'ini qiladi. gRPC **client stub(mijoz stubi)** ni ikkilik formatga kodlaydi va uni past darajadagi transport qatlamiga yuboradi.
-Step 5: gRPC sends the packets over the network via HTTP2. Because of binary encoding and network optimizations, gRPC is said to be 5X faster than JSON.
+5-qadam: gRPC paketlarni HTTP2 orqali tarmoq orqali yuboradi. Ikkilik kodlash va tarmoqni optimallashtirish tufayli gRPC JSONga qaraganda 5X tezroq deb aytiladi.
-Steps 6 - 8: The payment service (gRPC server) receives the packets from the network, decodes them, and invokes the server application.
+6-8-qadamlar: Toʻlov xizmati (gRPC serveri) tarmoqdan paketlarni qabul qiladi, ularni dekodlaydi va server ilovasini ishga tushiradi.
-Steps 9 - 11: The result is returned from the server application, and gets encoded and sent to the transport layer.
+9-11-qadamlar: Natija server ilovasidan qaytariladi va kodlanadi va transport qatlamiga yuboriladi.
-Steps 12 - 14: The order service receives the packets, decodes them, and sends the result to the client application.
+12-14-qadamlar: Buyurtma xizmati paketlarni qabul qiladi, ularni dekodlaydi va natijani mijoz ilovasiga yuboradi.
-### What is a webhook?
+### Webhook nima?
-The diagram below shows a comparison between polling and Webhook.
+Quyidagi diagrammada so'rov va Webhook o'rtasidagi taqqoslash ko'rsatilgan.
-Assume we run an eCommerce website. The clients send orders to the order service via the API gateway, which goes to the payment service for payment transactions. The payment service then talks to an external payment service provider (PSP) to complete the transactions.
+Faraz qilaylik, biz elektron tijorat veb-saytini ishga tushiramiz. Mijozlar to'lov operatsiyalari uchun to'lov xizmatiga o'tadigan API shlyuzi orqali buyurtma xizmatiga buyurtma yuboradilar. Keyin to'lov xizmati tranzaktsiyalarni bajarish uchun tashqi to'lov xizmati provayderi (PSP) bilan gaplashadi.
-There are two ways to handle communications with the external PSP.
+Tashqi PSP bilan aloqa qilishning ikki yo'li mavjud.
-**1. Short polling**
+**1. Short polling(Qisqa ovoz berish)**
-After sending the payment request to the PSP, the payment service keeps asking the PSP about the payment status. After several rounds, the PSP finally returns with the status.
+To'lov so'rovi PSP ga yuborilgandan so'ng, to'lov xizmati PSP dan to'lov holati haqida so'rashda davom etadi. Bir necha turdan so'ng, PSP nihoyat holatga qaytadi.
-Short polling has two drawbacks:
-* Constant polling of the status requires resources from the payment service.
-* The External service communicates directly with the payment service, creating security vulnerabilities.
+Qisqa so'rovning ikkita kamchiligi bor:
+* Doimiy ravishda vaziyatni so'rash to'lov xizmatidan resurslarni talab qiladi.
+* Tashqi xizmat to'lov xizmati bilan to'g'ridan-to'g'ri bog'lanib, xavfsizlik zaifliklarini yaratadi.
-**2. Webhook**
+**2. Webhook**
-We can register a webhook with the external service. It means: call me back at a certain URL when you have updates on the request. When the PSP has completed the processing, it will invoke the HTTP request to update the payment status.
+Biz webhukni tashqi xizmatda ro'yxatdan o'tkazishimiz mumkin. Buning ma'nosi: so'rov bo'yicha yangilanishlar mavjud bo'lganda, menga ma'lum bir URL orqali qo'ng'iroq qiling. PSP qayta ishlashni tugatgandan so'ng, to'lov holatini yangilash uchun HTTP so'rovini chaqiradi.
-In this way, the programming paradigm is changed, and the payment service doesn’t need to waste resources to poll the payment status anymore.
+Shu tarzda, dasturlash paradigmasi o'zgartiriladi va to'lov xizmati endi to'lov holatini so'rash uchun resurslarni isrof qilishiga hojat yo'q.
-What if the PSP never calls back? We can set up a housekeeping job to check payment status every hour.
+Agar PSP hech qachon qo'ng'iroq qilmasa nima bo'ladi? Biz har soatda to'lov holatini tekshirish uchun uy ishlarini o'rnatishimiz mumkin.
-Webhooks are often referred to as reverse APIs or push APIs because the server sends HTTP requests to the client. We need to pay attention to 3 things when using a webhook:
+WebhooksWebhuklar ko'pincha teskari API yoki push API deb ataladi, chunki server mijozga HTTP so'rovlarini yuboradi. Webhukdan foydalanishda 3 narsaga e'tibor qaratishimiz kerak:
-1. We need to design a proper API for the external service to call.
-2. We need to set up proper rules in the API gateway for security reasons.
-3. We need to register the correct URL at the external service.
+1. Biz tashqi xizmat qo'ng'iroq qilish uchun tegishli APIni loyihalashimiz kerak.
+2. Xavfsizlik nuqtai nazaridan API shlyuzida tegishli qoidalarni o'rnatishimiz kerak.
+3. Biz tashqi xizmatda to'g'ri URL manzilini ro'yxatdan o'tkazishimiz kerak.
-### How to improve API performance?
+### API ish faoliyatini qanday yaxshilash mumkin?
-The diagram below shows 5 common tricks to improve API performance.
+Quyidagi diagrammada API ish faoliyatini yaxshilash uchun 5 ta umumiy hiyla ko'rsatilgan.
-Pagination
+Pagination(Sahifalar)
-This is a common optimization when the size of the result is large. The results are streaming back to the client to improve the service responsiveness.
+Natijaning o'lchami katta bo'lsa, bu keng tarqalgan optimallashtirishdir. Natijalar xizmatning javob berish qobiliyatini yaxshilash uchun mijozga qaytariladi.
-Asynchronous Logging
+Asynchronous Logging(Asinxron ro'yxatga olish)
-Synchronous logging deals with the disk for every call and can slow down the system. Asynchronous logging sends logs to a lock-free buffer first and immediately returns. The logs will be flushed to the disk periodically. This significantly reduces the I/O overhead.
+Sinxron ro'yxatga olish har bir qo'ng'iroq uchun disk bilan ishlaydi va tizimni sekinlashtirishi mumkin. Asinxron ro'yxatga olish jurnallarni avval qulflanmagan buferga yuboradi va darhol qaytadi. Jurnallar diskka vaqti-vaqti bilan tozalanadi. Bu kiritish-chiqarish xarajatlarini sezilarli darajada kamaytiradi.
-Caching
+Caching(Keshlash)
-We can cache frequently accessed data into a cache. The client can query the cache first instead of visiting the database directly. If there is a cache miss, the client can query from the database. Caches like Redis store data in memory, so the data access is much faster than the database.
+Biz tez-tez foydalaniladigan ma'lumotlarni keshga saqlashimiz mumkin. Mijoz to'g'ridan-to'g'ri ma'lumotlar bazasiga tashrif buyurish o'rniga, avval keshni so'rashi mumkin. Agar kesh o'tkazib yuborilgan bo'lsa, mijoz ma'lumotlar bazasidan so'rashi mumkin. Redis kabi keshlar ma'lumotlarni xotirada saqlaydi, shuning uchun ma'lumotlarga kirish ma'lumotlar bazasiga qaraganda ancha tezroq.
-Payload Compression
+Payload Compression(Yuk yukini siqish)
-The requests and responses can be compressed using gzip etc so that the transmitted data size is much smaller. This speeds up the upload and download.
+So'rovlar va javoblar uzatiladigan ma'lumotlar hajmi ancha kichik bo'lishi uchun gzip va boshqalar yordamida siqilishi mumkin. Bu yuklash va yuklab olishni tezlashtiradi.
-Connection Pool
+Connection Pool(Aloqa hovuzi)
-When accessing resources, we often need to load data from the database. Opening the closing db connections adds significant overhead. So we should connect to the db via a pool of open connections. The connection pool is responsible for managing the connection lifecycle.
+Resurslarga kirishda biz ko'pincha ma'lumotlar bazasidan ma'lumotlarni yuklashimiz kerak. Yopuvchi db ulanishlarini ochish sezilarli yukni oshiradi. Shunday qilib, biz DB ga ochiq ulanishlar hovuzi orqali ulanishimiz kerak. Ulanish havzasi ulanishning hayot aylanishini boshqarish uchun javobgardir.
### HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)
@@ -291,7 +291,7 @@ The diagram below illustrates the key features.
QUIC is based on UDP. It introduces streams as first-class citizens at the transport layer. QUIC streams share the same QUIC connection, so no additional handshakes and slow starts are required to create new ones, but QUIC streams are delivered independently such that in most cases packet loss affecting one stream doesn't affect others.
-### SOAP vs REST vs GraphQL vs RPC
+### SOAP va REST va GraphQL va RPC
The diagram below illustrates the API timeline and API styles comparison.
@@ -304,7 +304,7 @@ You can check out the use cases of each style in the diagram.
-### Code First vs. API First
+### Code First va API First
The diagram below shows the differences between code-first development and API-first development. Why do we want to consider API first design?
@@ -329,7 +329,7 @@ The possibility of having surprises toward the end of the project lifecycle is r
Because we have designed the API first, the tests can be designed while the code is being developed. In a way, we also have TDD (Test Driven Design) when using API first development.
-### HTTP status codes
+### HTTP holat kodlari
@@ -344,7 +344,7 @@ Redirection (300-399)
Client Error (400-499)
Server Error (500-599)
-### What does API gateway do?
+### API shlyuzi nima qiladi?
The diagram below shows the details.
@@ -368,7 +368,7 @@ Step 8 - The API gateway transforms the request into the appropriate protocol an
Steps 9-12: The API gateway can handle errors properly, and deals with faults if the error takes a longer time to recover (circuit break). It can also leverage ELK (Elastic-Logstash-Kibana) stack for logging and monitoring. We sometimes cache data in the API gateway.
-### How do we design effective and safe APIs?
+### Qanday qilib samarali va xavfsiz API-larni loyihalashtiramiz?
The diagram below shows typical API designs with a shopping cart example.
@@ -379,7 +379,7 @@ The diagram below shows typical API designs with a shopping cart example.
Note that API design is not just URL path design. Most of the time, we need to choose the proper resource names, identifiers, and path patterns. It is equally important to design proper HTTP header fields or to design effective rate-limiting rules within the API gateway.
-### TCP/IP encapsulation
+### TCP/IP inkapsulyatsiyasi
How is data sent over the network? Why do we need so many layers in the OSI model?
@@ -403,7 +403,7 @@ Steps 6-10: When Device B receives the bits from the network, it performs the de
We need layers in the network model because each layer focuses on its own responsibilities. Each layer can rely on the headers for processing instructions and does not need to know the meaning of the data from the last layer.
-### Why is Nginx called a “reverse” proxy?
+### Nima uchun Nginx "teskari" proksi-server deb ataladi?
The diagram below shows the differences between a 𝐟𝐨𝐫𝐰𝐚𝐫𝐝 𝐩𝐫𝐨𝐱𝐲 and a 𝐫𝐞𝐯𝐞𝐫𝐬𝐞 𝐩𝐫𝐨𝐱𝐲.
@@ -428,7 +428,7 @@ A reverse proxy is good for:
3. Caching static contents
4. Encrypting and decrypting SSL communications
-### What are the common load-balancing algorithms?
+### Umumiy yuklarni muvozanatlash algoritmlari qanday?
The diagram below shows 6 common algorithms.
@@ -464,7 +464,7 @@ The diagram below shows 6 common algorithms.
A new request is sent to the service instance with the fastest response time.
-### URL, URI, URN - Do you know the differences?
+### URL, URI, URN - Farqlarni bilasizmi?
The diagram below shows a comparison of URL, URI, and URN.
From b0631409a7aa3bcb4c8d96e655b018e939ef7936 Mon Sep 17 00:00:00 2001
From: realtemirov
Date: Mon, 20 Nov 2023 21:49:12 +0500
Subject: [PATCH 3/8] URL, URI, URN - Do you know the differences?
---
README.md | 318 +++----
translations/README-uz.md | 1718 ++++++++++++++++++++++++++++++++++++-
2 files changed, 1876 insertions(+), 160 deletions(-)
diff --git a/README.md b/README.md
index aad74d2..f9c20ff 100644
--- a/README.md
+++ b/README.md
@@ -24,139 +24,139 @@ Whether you're preparing for a System Design Interview or you simply want to und
-- [Aloqa protokollari](#aloqa-protokollari)
- - [REST API va GraphQL](#rest-api-va-graphql)
- - [gRPC qanday ishlaydi?](#grpc-qanday-ishlaydi)
- - [Webhook nima?](#webhook-nima)
- - [API ish faoliyatini qanday yaxshilash mumkin?](#api-ish-faoliyatini-qanday-yaxshilash-mumkin)
- - [HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)](#http-10---http-11---http-20---http-30-quic)
- - [SOAP va REST va GraphQL va RPC](#soap-va-rest-va-graphql-va-rpc)
- - [Code First va API First](#code-first-va-api-first)
- - [HTTP holat kodlari](#http-holat-kodlari)
- - [API shlyuzi nima qiladi?](#api-shlyuzi-nima-qiladi)
- - [Qanday qilib samarali va xavfsiz API-larni loyihalashtiramiz?](#qanday-qilib-samarali-va-xavfsiz-api-larni-loyihalashtiramiz)
- - [TCP/IP inkapsulyatsiyasi](#tcpip-inkapsulyatsiyasi)
- - [Nima uchun Nginx "teskari" proksi-server deb ataladi?](#nima-uchun-nginx-teskari-proksi-server-deb-ataladi)
- - [Umumiy yuklarni muvozanatlash algoritmlari qanday?](#umumiy-yuklarni-muvozanatlash-algoritmlari-qanday)
- - [URL, URI, URN - Farqlarni bilasizmi?](#url-uri-urn---farqlarni-bilasizmi)
+- [Communication protocols](#communication-protocols)
+ - [REST API vs. GraphQL](#rest-api-vs-graphql)
+ - [How does gRPC work?](#how-does-grpc-work)
+ - [What is a webhook?](#what-is-a-webhook)
+ - [How to improve API performance?](#how-to-improve-api-performance)
+ - [HTTP 1.0 -\> HTTP 1.1 -\> HTTP 2.0 -\> HTTP 3.0 (QUIC)](#http-10---http-11---http-20---http-30-quic)
+ - [SOAP vs REST vs GraphQL vs RPC](#soap-vs-rest-vs-graphql-vs-rpc)
+ - [Code First vs. API First](#code-first-vs-api-first)
+ - [HTTP status codes](#http-status-codes)
+ - [What does API gateway do?](#what-does-api-gateway-do)
+ - [How do we design effective and safe APIs?](#how-do-we-design-effective-and-safe-apis)
+ - [TCP/IP encapsulation](#tcpip-encapsulation)
+ - [Why is Nginx called a “reverse” proxy?](#why-is-nginx-called-a-reverse-proxy)
+ - [What are the common load-balancing algorithms?](#what-are-the-common-load-balancing-algorithms)
+ - [URL, URI, URN - Do you know the differences?](#url-uri-urn---do-you-know-the-differences)
- [CI/CD](#cicd)
- - [CI/CD quvur liniyasi oddiy so'zlar bilan tushuntirilgan](#cicd-pipeline-explained-in-simple-terms)
+ - [CI/CD Pipeline Explained in Simple Terms](#cicd-pipeline-explained-in-simple-terms)
- [Netflix Tech Stack (CI/CD Pipeline)](#netflix-tech-stack-cicd-pipeline)
-- [Arxitektura naqshlari](#architecture-patterns)
- - [MVC, MVP, MVVM, MVVM-C va VIPER](#mvc-mvp-mvvm-mvvm-c-and-viper)
- - [Har bir dasturchi bilishi kerak bo'lgan 18 ta asosiy dizayn naqshlari](#18-key-design-patterns-every-developer-should-know)
-- [Ma'lumotlar bazasi](#database)
- - [Bulutli xizmatlardagi turli xil ma'lumotlar bazalarining chiroyli cheat varag'i ](#a-nice-cheat-sheet-of-different-databases-in-cloud-services)
- - [Ma'lumotlar bazalaringizni quvvatlantiradigan 8 ta ma'lumotlar tuzilmasi](#8-data-structures-that-power-your-databases)
- - [Ma'lumotlar bazasida SQL operatori qanday bajariladi?](#how-is-an-sql-statement-executed-in-the-database)
- - [CAP teoremasi](#cap-theorem)
- - [Xotira va saqlash turlari](#types-of-memory-and-storage)
- - [SQL so'rovini vizualizatsiya qilish](#visualizing-a-sql-query)
- - [SQL tili](#sql-language)
-- [Kesh](#cache)
- - [Ma'lumotlar hamma joyda keshlangan](#data-is-cached-everywhere)
- - [Nima uchun Redis juda tez?](#why-is-redis-so-fast)
- - [Redis-dan qanday foydalanish mumkin?](#how-can-redis-be-used)
- - [Eng yaxshi keshlash strategiyalari](#top-caching-strategies)
-- [Mikroservis arxitekturasi](#microservice-architecture)
- - [Oddiy mikroservis arxitekturasi nimaga o'xshaydi?](#what-does-a-typical-microservice-architecture-look-like)
- - [Mikroservisning eng yaxshi amaliyotlari](#microservice-best-practices)
- - [Mikroservislar uchun qanday texnologik stek ishlatiladi?](#what-tech-stack-is-commonly-used-for-microservices)
- - [Nega Kafka tez](#why-is-kafka-fast)
-- [To'lov tizimlari](#payment-systems)
- - [To'lov tizimini qanday o'rganish mumkin?](#how-to-learn-payment-systems)
- - [Nima uchun kredit karta "banklardagi eng daromadli mahsulot" deb ataladi? VISA/Mastercard qanday qilib pul ishlaydi?](#why-is-the-credit-card-called-the-most-profitable-product-in-banks-how-does-visamastercard-make-money)
- - [Savdogarlar do'konida kredit kartani o'tkazganimizda VISA qanday ishlaydi?](#how-does-visa-work-when-we-swipe-a-credit-card-at-a-merchants-shop)
- - [Dunyo bo'ylab to'lov tizimlari seriyasi (1-qism): Hindistonda yagona to'lov interfeysi (UPI)](#payment-systems-around-the-world-series-part-1-unified-payments-interface-upi-in-india)
+- [Architecture patterns](#architecture-patterns)
+ - [MVC, MVP, MVVM, MVVM-C, and VIPER](#mvc-mvp-mvvm-mvvm-c-and-viper)
+ - [18 Key Design Patterns Every Developer Should Know](#18-key-design-patterns-every-developer-should-know)
+- [Database](#database)
+ - [A nice cheat sheet of different databases in cloud services](#a-nice-cheat-sheet-of-different-databases-in-cloud-services)
+ - [8 Data Structures That Power Your Databases](#8-data-structures-that-power-your-databases)
+ - [How is an SQL statement executed in the database?](#how-is-an-sql-statement-executed-in-the-database)
+ - [CAP theorem](#cap-theorem)
+ - [Types of Memory and Storage](#types-of-memory-and-storage)
+ - [Visualizing a SQL query](#visualizing-a-sql-query)
+ - [SQL language](#sql-language)
+- [Cache](#cache)
+ - [Data is cached everywhere](#data-is-cached-everywhere)
+ - [Why is Redis so fast?](#why-is-redis-so-fast)
+ - [How can Redis be used?](#how-can-redis-be-used)
+ - [Top caching strategies](#top-caching-strategies)
+- [Microservice architecture](#microservice-architecture)
+ - [What does a typical microservice architecture look like?](#what-does-a-typical-microservice-architecture-look-like)
+ - [Microservice Best Practices](#microservice-best-practices)
+ - [What tech stack is commonly used for microservices?](#what-tech-stack-is-commonly-used-for-microservices)
+ - [Why is Kafka fast](#why-is-kafka-fast)
+- [Payment systems](#payment-systems)
+ - [How to learn payment systems?](#how-to-learn-payment-systems)
+ - [Why is the credit card called “the most profitable product in banks”? How does VISA/Mastercard make money?](#why-is-the-credit-card-called-the-most-profitable-product-in-banks-how-does-visamastercard-make-money)
+ - [How does VISA work when we swipe a credit card at a merchant’s shop?](#how-does-visa-work-when-we-swipe-a-credit-card-at-a-merchants-shop)
+ - [Payment Systems Around The World Series (Part 1): Unified Payments Interface (UPI) in India](#payment-systems-around-the-world-series-part-1-unified-payments-interface-upi-in-india)
- [DevOps](#devops)
- - [DevOps va SRE va platforma muhandisligi. Farqi nimada?](#devops-vs-sre-vs-platform-engineering-what-is-the-difference)
- - [K8s (Kubernetes) nima?](#what-is-k8s-kubernetes)
- - [Docker va Kubernetes. Qaysi birini ishlatishimiz kerak?](#docker-vs-kubernetes-which-one-should-we-use)
- - [Docker qanday ishlaydi?](#how-does-docker-work)
+ - [DevOps vs. SRE vs. Platform Engineering. What is the difference?](#devops-vs-sre-vs-platform-engineering-what-is-the-difference)
+ - [What is k8s (Kubernetes)?](#what-is-k8s-kubernetes)
+ - [Docker vs. Kubernetes. Which one should we use?](#docker-vs-kubernetes-which-one-should-we-use)
+ - [How does Docker work?](#how-does-docker-work)
- [GIT](#git)
- - [Git buyruqlari qanday ishlaydi](#how-git-commands-work)
- - [Git qanday ishlaydi?](#how-does-git-work)
- - [Git merge va Git rebase](#git-merge-vs-git-rebase)
-- [Bulutli xizmatlar](#cloud-services)
- - [Turli xil bulut xizmatlarining chiroyli cheat varag'i (2023 yil nashri)](#a-nice-cheat-sheet-of-different-cloud-services-2023-edition)
- - [Mahalliy bulut nima?](#what-is-cloud-native)
-- [Ishlab chiquvchi mahsuldorlik vositalari](#developer-productivity-tools)
- - [JSON fayllarini vizualizatsiya qilish](#visualize-json-files)
- - [Kodni avtomatik ravishda arxitektura diagrammalariga aylantiring](#automatically-turn-code-into-architecture-diagrams)
+ - [How Git Commands work](#how-git-commands-work)
+ - [How does Git Work?](#how-does-git-work)
+ - [Git merge vs. Git rebase](#git-merge-vs-git-rebase)
+- [Cloud Services](#cloud-services)
+ - [A nice cheat sheet of different cloud services (2023 edition)](#a-nice-cheat-sheet-of-different-cloud-services-2023-edition)
+ - [What is cloud native?](#what-is-cloud-native)
+- [Developer productivity tools](#developer-productivity-tools)
+ - [Visualize JSON files](#visualize-json-files)
+ - [Automatically turn code into architecture diagrams](#automatically-turn-code-into-architecture-diagrams)
- [Linux](#linux)
- - [Linux fayl tizimi tushuntirildi](#linux-file-system-explained)
- - [Siz bilishingiz kerak bo'lgan 18 ta eng ko'p ishlatiladigan Linux buyruqlari](#18-most-used-linux-commands-you-should-know)
-- [Xavfsizlik](#security)
- - [HTTPS qanday ishlaydi?](#how-does-https-work)
- - [Oauth 2.0 oddiy shartlar bilan tushuntirilgan.](#oauth-20-explained-with-simple-terms)
- - [Autentifikatsiya mexanizmlarining 4 ta eng yaxshi shakllari](#top-4-forms-of-authentication-mechanisms)
- - [Sessiya, cookie, JWT, token, SSO va OAuth 2.0 - ular nima?](#session-cookie-jwt-token-sso-and-oauth-20---what-are-they)
- - [Ma'lumotlar bazasida parollarni qanday xavfsiz saqlash va parolni qanday tekshirish mumkin?](#how-to-store-passwords-safely-in-the-database-and-how-to-validate-a-password)
- - [10 yoshli bolaga JSON Web Token (JWT) haqida tushuntirish](#explaining-json-web-token-jwt-to-a-10-year-old-kid)
- - [Google Authenticator (yoki 2 faktorli autentifikatsiyaning boshqa turlari) qanday ishlaydi?](#how-does-google-authenticator-or-other-types-of-2-factor-authenticators-work)
-- [Haqiqiy dunyo misollari](#real-world-case-studies)
- - [Netflixning Tech Stacki](#netflixs-tech-stack)
- - [Twitter arxitekturasi 2022](#twitter-architecture-2022)
- - [Oxirgi 15 yil ichida Airbnb mikroservis arxitekturasining evolyutsiyasi](#evolution-of-airbnbs-microservice-architecture-over-the-past-15-years)
- - [Monorepo va mikrorepo.](#monorepo-vs-microrepo)
- - [Stack Overflow veb-saytini qanday loyihalashtirasiz?](#how-will-you-design-the-stack-overflow-website)
- - [Nima uchun Amazon Prime Video monitoringi serversizdan monolitga o'tdi? Qanday qilib 90% xarajatlarni tejash mumkin?](#why-did-amazon-prime-video-monitoring-move-from-serverless-to-monolithic-how-can-it-save-90-cost)
- - [Disney Hotstar turnir davomida 5 milliard kulgichni qanday suratga oladi?](#how-does-disney-hotstar-capture-5-billion-emojis-during-a-tournament)
- - [Discord qanday qilib trillionlab xabarlarni saqlaydi](#how-discord-stores-trillions-of-messages)
- - [YouTube, TikTok live yoki Twitch-da jonli video oqimlari qanday ishlaydi?](#how-do-video-live-streamings-work-on-youtube-tiktok-live-or-twitch)
+ - [Linux file system explained](#linux-file-system-explained)
+ - [18 Most-used Linux Commands You Should Know](#18-most-used-linux-commands-you-should-know)
+- [Security](#security)
+ - [How does HTTPS work?](#how-does-https-work)
+ - [Oauth 2.0 Explained With Simple Terms.](#oauth-20-explained-with-simple-terms)
+ - [Top 4 Forms of Authentication Mechanisms](#top-4-forms-of-authentication-mechanisms)
+ - [Session, cookie, JWT, token, SSO, and OAuth 2.0 - what are they?](#session-cookie-jwt-token-sso-and-oauth-20---what-are-they)
+ - [How to store passwords safely in the database and how to validate a password?](#how-to-store-passwords-safely-in-the-database-and-how-to-validate-a-password)
+ - [Explaining JSON Web Token (JWT) to a 10 year old Kid](#explaining-json-web-token-jwt-to-a-10-year-old-kid)
+ - [How does Google Authenticator (or other types of 2-factor authenticators) work?](#how-does-google-authenticator-or-other-types-of-2-factor-authenticators-work)
+- [Real World Case Studies](#real-world-case-studies)
+ - [Netflix's Tech Stack](#netflixs-tech-stack)
+ - [Twitter Architecture 2022](#twitter-architecture-2022)
+ - [Evolution of Airbnb’s microservice architecture over the past 15 years](#evolution-of-airbnbs-microservice-architecture-over-the-past-15-years)
+ - [Monorepo vs. Microrepo.](#monorepo-vs-microrepo)
+ - [How will you design the Stack Overflow website?](#how-will-you-design-the-stack-overflow-website)
+ - [Why did Amazon Prime Video monitoring move from serverless to monolithic? How can it save 90% cost?](#why-did-amazon-prime-video-monitoring-move-from-serverless-to-monolithic-how-can-it-save-90-cost)
+ - [How does Disney Hotstar capture 5 Billion Emojis during a tournament?](#how-does-disney-hotstar-capture-5-billion-emojis-during-a-tournament)
+ - [How Discord Stores Trillions Of Messages](#how-discord-stores-trillions-of-messages)
+ - [How do video live streamings work on YouTube, TikTok live, or Twitch?](#how-do-video-live-streamings-work-on-youtube-tiktok-live-or-twitch)
-## Aloqa protokollari
+## Communication protocols
-Arxitektura uslublari amaliy dasturlash interfeysining (API) turli komponentlari bir-biri bilan qanday o'zaro ta'sir qilishini belgilaydi.Natijada, ular API-larni loyihalash va qurishda standart yondashuvni ta'minlash orqali samaradorlik, ishonchlilik va boshqa tizimlar bilan integratsiya qulayligini ta'minlaydi. Bu erda eng ko'p ishlatiladigan uslublar:
+Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles:
-- SOAP:
-
- Yetuk, keng qamrovli, XML-ga asoslangan
+- SOAP:
+
+ Mature, comprehensive, XML-based
- Korporativ ilovalar uchun eng yaxshi
+ Best for enterprise applications
-- RESTful:
+- RESTful:
- Ommabop, amalga oshirish oson, HTTP usullari
+ Popular, easy-to-implement, HTTP methods
- Veb-xizmatlar uchun ideal
+ Ideal for web services
-- GraphQL:
+- GraphQL:
- So'rov tili, maxsus ma'lumotlarni so'rash
+ Query language, request specific data
- Tarmoq yukini kamaytiradi, tezroq javob beradi
+ Reduces network overhead, faster responses
-- gRPC:
+- gRPC:
- Zamonaviy, yuqori samarali, protokol buferlari
+ Modern, high-performance, Protocol Buffers
- Mikroservislar arxitekturasi uchun javob beradi
+ Suitable for microservices architectures
-- WebSocket:
+- WebSocket:
- Real-time, bidirectional, persistent connections
+ Real-time, bidirectional, persistent connections
- Kam kechikishli ma'lumotlar almashinuvi uchun juda mos keladi
+ Perfect for low-latency data exchange
-- Webhook:
+- Webhook:
- Voqealarga asoslangan, HTTP qo'ng'iroqlari, asinxron
+ Event-driven, HTTP callbacks, asynchronous
- Voqea sodir bo'lganda tizimlarni xabardor qiladi
+ Notifies systems when events occur
-### REST API va GraphQL
+### REST API vs. GraphQL
-API dizayni haqida gap ketganda, REST va GraphQL har birining kuchli va zaif tomonlari bor.
+When it comes to API design, REST and GraphQL each have their own strengths and weaknesses.
-Quyidagi diagrammada REST va GraphQL o'rtasidagi tezkor taqqoslash ko'rsatilgan.
+The diagram below shows a quick comparison between REST and GraphQL.
@@ -164,108 +164,108 @@ Quyidagi diagrammada REST va GraphQL o'rtasidagi tezkor taqqoslash ko'rsatilgan.
REST
-- CRUD operatsiyalari uchun GET, POST, PUT, DELETE kabi standart HTTP usullaridan foydalanadi.
-- Alohida xizmatlar/ilovalar o'rtasida oddiy, bir xil interfeyslar kerak bo'lganda yaxshi ishlaydi.
-- Keshlash strategiyalarini amalga oshirish oson.
-- Salbiy tomoni shundaki, u alohida so'nggi nuqtalardan tegishli ma'lumotlarni yig'ish uchun bir nechta aylanishlarni talab qilishi mumkin.
+- Uses standard HTTP methods like GET, POST, PUT, DELETE for CRUD operations.
+- Works well when you need simple, uniform interfaces between separate services/applications.
+- Caching strategies are straightforward to implement.
+- The downside is it may require multiple roundtrips to assemble related data from separate endpoints.
GraphQL
-- Mijozlarga kerakli ma'lumotlarni aniq so'rashlari uchun yagona so'nggi nuqtani taqdim etadi.
-- Mijozlar ichki so'rovlarda talab qilinadigan aniq maydonlarni belgilaydi va server faqat shu maydonlarni o'z ichiga olgan optimallashtirilgan foydali yuklarni qaytaradi.
-- Ma'lumotlarni o'zgartirish uchun mutatsiyalarni va real vaqtda bildirishnomalar uchun obunalarni qo'llab-quvvatlaydi.
-- Bir nechta manbalardan ma'lumotlarni jamlash uchun ajoyib va tez rivojlanayotgan frontend talablari bilan yaxshi ishlaydi.
-- Biroq, u murakkablikni mijoz tomoniga o'tkazadi va agar to'g'ri himoyalanmagan bo'lsa, haqoratli so'rovlarga ruxsat berishi mumkin.
-- Keshlash strategiyalari RESTga qaraganda murakkabroq bo'lishi mumkin.
+- Provides a single endpoint for clients to query for precisely the data they need.
+- Clients specify the exact fields required in nested queries, and the server returns optimized payloads containing just those fields.
+- Supports Mutations for modifying data and Subscriptions for real-time notifications.
+- Great for aggregating data from multiple sources and works well with rapidly evolving frontend requirements.
+- However, it shifts complexity to the client side and can allow abusive queries if not properly safeguarded
+- Caching strategies can be more complicated than REST.
-REST va GraphQL o'rtasidagi eng yaxshi tanlov dastur va ishlab chiqish guruhining o'ziga xos talablariga bog'liq. GraphQL murakkab yoki tez-tez o'zgaruvchan frontend ehtiyojlari uchun juda mos keladi, REST esa oddiy va izchil shartnomalar afzal ko'rilgan ilovalarga mos keladi.
+The best choice between REST and GraphQL depends on the specific requirements of the application and development team. GraphQL is a good fit for complex or frequently changing frontend needs, while REST suits applications where simple and consistent contracts are preferred.
-Hech bir API yondashuvi kumush o'q emas. To'g'ri uslubni tanlash uchun talablar va kelishuvlarni diqqat bilan baholash muhimdir. REST va GraphQL ikkalasi ham ma'lumotlarni oshkor qilish va zamonaviy ilovalarni quvvatlantirish uchun to'g'ri tanlovdir.
+Neither API approach is a silver bullet. Carefully evaluating requirements and tradeoffs is important to pick the right style. Both REST and GraphQL are valid options for exposing data and powering modern applications.
-### gRPC qanday ishlaydi?
+### How does gRPC work?
-RPC (Remote Procedure Call) "**remote(masofaviy)**" deb nomlanadi, chunki u xizmatlar mikroservis arxitekturasi ostida turli serverlarga o'rnatilganda masofaviy xizmatlar o'rtasida aloqa o'rnatish imkonini beradi. Foydalanuvchi nuqtai nazaridan, u mahalliy funktsiya chaqiruvi kabi ishlaydi.
+RPC (Remote Procedure Call) is called “**remote**” because it enables communications between remote services when services are deployed to different servers under microservice architecture. From the user’s point of view, it acts like a local function call.
-Quyidagi diagramma **gRPC** uchun umumiy ma'lumotlar oqimini ko'rsatadi.
+The diagram below illustrates the overall data flow for **gRPC**.
-1-qadam: REST qo'ng'irog'i mijozdan amalga oshiriladi. So'rovning asosiy qismi odatda JSON formatida bo'ladi.
+Step 1: A REST call is made from the client. The request body is usually in JSON format.
-2-4-qadamlar: Buyurtma xizmati (gRPC mijozi) REST qo'ng'irog'ini qabul qiladi, uni o'zgartiradi va to'lov xizmatiga RPC qo'ng'irog'ini qiladi. gRPC **client stub(mijoz stubi)** ni ikkilik formatga kodlaydi va uni past darajadagi transport qatlamiga yuboradi.
+Steps 2 - 4: The order service (gRPC client) receives the REST call, transforms it, and makes an RPC call to the payment service. gRPC encodes the **client stub** into a binary format and sends it to the low-level transport layer.
-5-qadam: gRPC paketlarni HTTP2 orqali tarmoq orqali yuboradi. Ikkilik kodlash va tarmoqni optimallashtirish tufayli gRPC JSONga qaraganda 5X tezroq deb aytiladi.
+Step 5: gRPC sends the packets over the network via HTTP2. Because of binary encoding and network optimizations, gRPC is said to be 5X faster than JSON.
-6-8-qadamlar: Toʻlov xizmati (gRPC serveri) tarmoqdan paketlarni qabul qiladi, ularni dekodlaydi va server ilovasini ishga tushiradi.
+Steps 6 - 8: The payment service (gRPC server) receives the packets from the network, decodes them, and invokes the server application.
-9-11-qadamlar: Natija server ilovasidan qaytariladi va kodlanadi va transport qatlamiga yuboriladi.
+Steps 9 - 11: The result is returned from the server application, and gets encoded and sent to the transport layer.
-12-14-qadamlar: Buyurtma xizmati paketlarni qabul qiladi, ularni dekodlaydi va natijani mijoz ilovasiga yuboradi.
+Steps 12 - 14: The order service receives the packets, decodes them, and sends the result to the client application.
-### Webhook nima?
+### What is a webhook?
-Quyidagi diagrammada so'rov va Webhook o'rtasidagi taqqoslash ko'rsatilgan.
+The diagram below shows a comparison between polling and Webhook.
-Faraz qilaylik, biz elektron tijorat veb-saytini ishga tushiramiz. Mijozlar to'lov operatsiyalari uchun to'lov xizmatiga o'tadigan API shlyuzi orqali buyurtma xizmatiga buyurtma yuboradilar. Keyin to'lov xizmati tranzaktsiyalarni bajarish uchun tashqi to'lov xizmati provayderi (PSP) bilan gaplashadi.
+Assume we run an eCommerce website. The clients send orders to the order service via the API gateway, which goes to the payment service for payment transactions. The payment service then talks to an external payment service provider (PSP) to complete the transactions.
-Tashqi PSP bilan aloqa qilishning ikki yo'li mavjud.
+There are two ways to handle communications with the external PSP.
-**1. Short polling(Qisqa ovoz berish)**
+**1. Short polling**
-To'lov so'rovi PSP ga yuborilgandan so'ng, to'lov xizmati PSP dan to'lov holati haqida so'rashda davom etadi. Bir necha turdan so'ng, PSP nihoyat holatga qaytadi.
+After sending the payment request to the PSP, the payment service keeps asking the PSP about the payment status. After several rounds, the PSP finally returns with the status.
-Qisqa so'rovning ikkita kamchiligi bor:
-* Doimiy ravishda vaziyatni so'rash to'lov xizmatidan resurslarni talab qiladi.
-* Tashqi xizmat to'lov xizmati bilan to'g'ridan-to'g'ri bog'lanib, xavfsizlik zaifliklarini yaratadi.
+Short polling has two drawbacks:
+* Constant polling of the status requires resources from the payment service.
+* The External service communicates directly with the payment service, creating security vulnerabilities.
-**2. Webhook**
+**2. Webhook**
-Biz webhukni tashqi xizmatda ro'yxatdan o'tkazishimiz mumkin. Buning ma'nosi: so'rov bo'yicha yangilanishlar mavjud bo'lganda, menga ma'lum bir URL orqali qo'ng'iroq qiling. PSP qayta ishlashni tugatgandan so'ng, to'lov holatini yangilash uchun HTTP so'rovini chaqiradi.
+We can register a webhook with the external service. It means: call me back at a certain URL when you have updates on the request. When the PSP has completed the processing, it will invoke the HTTP request to update the payment status.
-Shu tarzda, dasturlash paradigmasi o'zgartiriladi va to'lov xizmati endi to'lov holatini so'rash uchun resurslarni isrof qilishiga hojat yo'q.
+In this way, the programming paradigm is changed, and the payment service doesn’t need to waste resources to poll the payment status anymore.
-Agar PSP hech qachon qo'ng'iroq qilmasa nima bo'ladi? Biz har soatda to'lov holatini tekshirish uchun uy ishlarini o'rnatishimiz mumkin.
+What if the PSP never calls back? We can set up a housekeeping job to check payment status every hour.
-WebhooksWebhuklar ko'pincha teskari API yoki push API deb ataladi, chunki server mijozga HTTP so'rovlarini yuboradi. Webhukdan foydalanishda 3 narsaga e'tibor qaratishimiz kerak:
+Webhooks are often referred to as reverse APIs or push APIs because the server sends HTTP requests to the client. We need to pay attention to 3 things when using a webhook:
-1. Biz tashqi xizmat qo'ng'iroq qilish uchun tegishli APIni loyihalashimiz kerak.
-2. Xavfsizlik nuqtai nazaridan API shlyuzida tegishli qoidalarni o'rnatishimiz kerak.
-3. Biz tashqi xizmatda to'g'ri URL manzilini ro'yxatdan o'tkazishimiz kerak.
+1. We need to design a proper API for the external service to call.
+2. We need to set up proper rules in the API gateway for security reasons.
+3. We need to register the correct URL at the external service.
-### API ish faoliyatini qanday yaxshilash mumkin?
+### How to improve API performance?
-Quyidagi diagrammada API ish faoliyatini yaxshilash uchun 5 ta umumiy hiyla ko'rsatilgan.
+The diagram below shows 5 common tricks to improve API performance.
-Pagination(Sahifalar)
+Pagination
-Natijaning o'lchami katta bo'lsa, bu keng tarqalgan optimallashtirishdir. Natijalar xizmatning javob berish qobiliyatini yaxshilash uchun mijozga qaytariladi.
+This is a common optimization when the size of the result is large. The results are streaming back to the client to improve the service responsiveness.
-Asynchronous Logging(Asinxron ro'yxatga olish)
+Asynchronous Logging
-Sinxron ro'yxatga olish har bir qo'ng'iroq uchun disk bilan ishlaydi va tizimni sekinlashtirishi mumkin. Asinxron ro'yxatga olish jurnallarni avval qulflanmagan buferga yuboradi va darhol qaytadi. Jurnallar diskka vaqti-vaqti bilan tozalanadi. Bu kiritish-chiqarish xarajatlarini sezilarli darajada kamaytiradi.
+Synchronous logging deals with the disk for every call and can slow down the system. Asynchronous logging sends logs to a lock-free buffer first and immediately returns. The logs will be flushed to the disk periodically. This significantly reduces the I/O overhead.
-Caching(Keshlash)
+Caching
-Biz tez-tez foydalaniladigan ma'lumotlarni keshga saqlashimiz mumkin. Mijoz to'g'ridan-to'g'ri ma'lumotlar bazasiga tashrif buyurish o'rniga, avval keshni so'rashi mumkin. Agar kesh o'tkazib yuborilgan bo'lsa, mijoz ma'lumotlar bazasidan so'rashi mumkin. Redis kabi keshlar ma'lumotlarni xotirada saqlaydi, shuning uchun ma'lumotlarga kirish ma'lumotlar bazasiga qaraganda ancha tezroq.
+We can cache frequently accessed data into a cache. The client can query the cache first instead of visiting the database directly. If there is a cache miss, the client can query from the database. Caches like Redis store data in memory, so the data access is much faster than the database.
-Payload Compression(Yuk yukini siqish)
+Payload Compression
-So'rovlar va javoblar uzatiladigan ma'lumotlar hajmi ancha kichik bo'lishi uchun gzip va boshqalar yordamida siqilishi mumkin. Bu yuklash va yuklab olishni tezlashtiradi.
+The requests and responses can be compressed using gzip etc so that the transmitted data size is much smaller. This speeds up the upload and download.
-Connection Pool(Aloqa hovuzi)
+Connection Pool
-Resurslarga kirishda biz ko'pincha ma'lumotlar bazasidan ma'lumotlarni yuklashimiz kerak. Yopuvchi db ulanishlarini ochish sezilarli yukni oshiradi. Shunday qilib, biz DB ga ochiq ulanishlar hovuzi orqali ulanishimiz kerak. Ulanish havzasi ulanishning hayot aylanishini boshqarish uchun javobgardir.
+When accessing resources, we often need to load data from the database. Opening the closing db connections adds significant overhead. So we should connect to the db via a pool of open connections. The connection pool is responsible for managing the connection lifecycle.
### HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)
@@ -291,7 +291,7 @@ The diagram below illustrates the key features.
QUIC is based on UDP. It introduces streams as first-class citizens at the transport layer. QUIC streams share the same QUIC connection, so no additional handshakes and slow starts are required to create new ones, but QUIC streams are delivered independently such that in most cases packet loss affecting one stream doesn't affect others.
-### SOAP va REST va GraphQL va RPC
+### SOAP vs REST vs GraphQL vs RPC
The diagram below illustrates the API timeline and API styles comparison.
@@ -304,7 +304,7 @@ You can check out the use cases of each style in the diagram.
-### Code First va API First
+### Code First vs. API First
The diagram below shows the differences between code-first development and API-first development. Why do we want to consider API first design?
@@ -329,7 +329,7 @@ The possibility of having surprises toward the end of the project lifecycle is r
Because we have designed the API first, the tests can be designed while the code is being developed. In a way, we also have TDD (Test Driven Design) when using API first development.
-### HTTP holat kodlari
+### HTTP status codes
@@ -344,7 +344,7 @@ Redirection (300-399)
Client Error (400-499)
Server Error (500-599)
-### API shlyuzi nima qiladi?
+### What does API gateway do?
The diagram below shows the details.
@@ -368,7 +368,7 @@ Step 8 - The API gateway transforms the request into the appropriate protocol an
Steps 9-12: The API gateway can handle errors properly, and deals with faults if the error takes a longer time to recover (circuit break). It can also leverage ELK (Elastic-Logstash-Kibana) stack for logging and monitoring. We sometimes cache data in the API gateway.
-### Qanday qilib samarali va xavfsiz API-larni loyihalashtiramiz?
+### How do we design effective and safe APIs?
The diagram below shows typical API designs with a shopping cart example.
@@ -379,7 +379,7 @@ The diagram below shows typical API designs with a shopping cart example.
Note that API design is not just URL path design. Most of the time, we need to choose the proper resource names, identifiers, and path patterns. It is equally important to design proper HTTP header fields or to design effective rate-limiting rules within the API gateway.
-### TCP/IP inkapsulyatsiyasi
+### TCP/IP encapsulation
How is data sent over the network? Why do we need so many layers in the OSI model?
@@ -403,7 +403,7 @@ Steps 6-10: When Device B receives the bits from the network, it performs the de
We need layers in the network model because each layer focuses on its own responsibilities. Each layer can rely on the headers for processing instructions and does not need to know the meaning of the data from the last layer.
-### Nima uchun Nginx "teskari" proksi-server deb ataladi?
+### Why is Nginx called a “reverse” proxy?
The diagram below shows the differences between a 𝐟𝐨𝐫𝐰𝐚𝐫𝐝 𝐩𝐫𝐨𝐱𝐲 and a 𝐫𝐞𝐯𝐞𝐫𝐬𝐞 𝐩𝐫𝐨𝐱𝐲.
@@ -428,7 +428,7 @@ A reverse proxy is good for:
3. Caching static contents
4. Encrypting and decrypting SSL communications
-### Umumiy yuklarni muvozanatlash algoritmlari qanday?
+### What are the common load-balancing algorithms?
The diagram below shows 6 common algorithms.
@@ -464,7 +464,7 @@ The diagram below shows 6 common algorithms.
A new request is sent to the service instance with the fastest response time.
-### URL, URI, URN - Farqlarni bilasizmi?
+### URL, URI, URN - Do you know the differences?
The diagram below shows a comparison of URL, URI, and URN.
@@ -1736,4 +1736,4 @@ Standard protocols for live streaming include:
## License
-
This work is licensed under CC BY-NC-ND 4.0
+This work is licensed under CC BY-NC-ND 4.0
\ No newline at end of file
diff --git a/translations/README-uz.md b/translations/README-uz.md
index e649443..bc5d3f4 100644
--- a/translations/README-uz.md
+++ b/translations/README-uz.md
@@ -1,5 +1,5 @@
- 
+ 
@@ -21,3 +21,1719 @@ Vizual va oddiy atamalar yordamida murakkab tizimlarni tushuning.
Tizim dizayni bo'yicha intervyuga tayyorlanyapsizmi yoki tizimlar qanday ishlashini tushunishni xohlaysizmi, umid qilamizki, ushbu repository sizga bunga erishishda yordam beradi.
# Mundarija
+
+
+
+- [Aloqa protokollari](#aloqa-protokollari)
+ - [REST API va GraphQL](#rest-api-va-graphql)
+ - [gRPC qanday ishlaydi?](#grpc-qanday-ishlaydi)
+ - [Webhook nima?](#webhook-nima)
+ - [API ish faoliyatini qanday yaxshilash mumkin?](#api-ish-faoliyatini-qanday-yaxshilash-mumkin)
+ - [HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)](#http-10---http-11---http-20---http-30-quic)
+ - [SOAP va REST va GraphQL va RPC](#soap-va-rest-va-graphql-va-rpc)
+ - [Code First va API First](#code-first-va-api-first)
+ - [HTTP holat kodlari](#http-holat-kodlari)
+ - [API shlyuzi nima qiladi?](#api-shlyuzi-nima-qiladi)
+ - [Qanday qilib samarali va xavfsiz API-larni loyihalashtiramiz?](#qanday-qilib-samarali-va-xavfsiz-api-larni-loyihalashtiramiz)
+ - [TCP/IP inkapsulyatsiyasi](#tcpip-inkapsulyatsiyasi)
+ - [Nima uchun Nginx "teskari" proksi-server deb ataladi?](#nima-uchun-nginx-teskari-proksi-server-deb-ataladi)
+ - [Umumiy yuklarni muvozanatlash algoritmlari qanday?](#umumiy-yuklarni-muvozanatlash-algoritmlari-qanday)
+ - [URL, URI, URN - Farqlarni bilasizmi?](#url-uri-urn---farqlarni-bilasizmi)
+- [CI/CD](#cicd)
+ - [CI/CD quvur liniyasi oddiy so'zlar bilan tushuntirilgan](#cicd-pipeline-explained-in-simple-terms)
+ - [Netflix Tech Stack (CI/CD Pipeline)](#netflix-tech-stack-cicd-pipeline)
+- [Arxitektura naqshlari](#architecture-patterns)
+ - [MVC, MVP, MVVM, MVVM-C va VIPER](#mvc-mvp-mvvm-mvvm-c-and-viper)
+ - [Har bir dasturchi bilishi kerak bo'lgan 18 ta asosiy dizayn naqshlari](#18-key-design-patterns-every-developer-should-know)
+- [Ma'lumotlar bazasi](#database)
+ - [Bulutli xizmatlardagi turli xil ma'lumotlar bazalarining chiroyli cheat varag'i ](#a-nice-cheat-sheet-of-different-databases-in-cloud-services)
+ - [Ma'lumotlar bazalaringizni quvvatlantiradigan 8 ta ma'lumotlar tuzilmasi](#8-data-structures-that-power-your-databases)
+ - [Ma'lumotlar bazasida SQL operatori qanday bajariladi?](#how-is-an-sql-statement-executed-in-the-database)
+ - [CAP teoremasi](#cap-theorem)
+ - [Xotira va saqlash turlari](#types-of-memory-and-storage)
+ - [SQL so'rovini vizualizatsiya qilish](#visualizing-a-sql-query)
+ - [SQL tili](#sql-language)
+- [Kesh](#cache)
+ - [Ma'lumotlar hamma joyda keshlangan](#data-is-cached-everywhere)
+ - [Nima uchun Redis juda tez?](#why-is-redis-so-fast)
+ - [Redis-dan qanday foydalanish mumkin?](#how-can-redis-be-used)
+ - [Eng yaxshi keshlash strategiyalari](#top-caching-strategies)
+- [Mikroservis arxitekturasi](#microservice-architecture)
+ - [Oddiy mikroservis arxitekturasi nimaga o'xshaydi?](#what-does-a-typical-microservice-architecture-look-like)
+ - [Mikroservisning eng yaxshi amaliyotlari](#microservice-best-practices)
+ - [Mikroservislar uchun qanday texnologik stek ishlatiladi?](#what-tech-stack-is-commonly-used-for-microservices)
+ - [Nega Kafka tez](#why-is-kafka-fast)
+- [To'lov tizimlari](#payment-systems)
+ - [To'lov tizimini qanday o'rganish mumkin?](#how-to-learn-payment-systems)
+ - [Nima uchun kredit karta "banklardagi eng daromadli mahsulot" deb ataladi? VISA/Mastercard qanday qilib pul ishlaydi?](#why-is-the-credit-card-called-the-most-profitable-product-in-banks-how-does-visamastercard-make-money)
+ - [Savdogarlar do'konida kredit kartani o'tkazganimizda VISA qanday ishlaydi?](#how-does-visa-work-when-we-swipe-a-credit-card-at-a-merchants-shop)
+ - [Dunyo bo'ylab to'lov tizimlari seriyasi (1-qism): Hindistonda yagona to'lov interfeysi (UPI)](#payment-systems-around-the-world-series-part-1-unified-payments-interface-upi-in-india)
+- [DevOps](#devops)
+ - [DevOps va SRE va platforma muhandisligi. Farqi nimada?](#devops-vs-sre-vs-platform-engineering-what-is-the-difference)
+ - [K8s (Kubernetes) nima?](#what-is-k8s-kubernetes)
+ - [Docker va Kubernetes. Qaysi birini ishlatishimiz kerak?](#docker-vs-kubernetes-which-one-should-we-use)
+ - [Docker qanday ishlaydi?](#how-does-docker-work)
+- [GIT](#git)
+ - [Git buyruqlari qanday ishlaydi](#how-git-commands-work)
+ - [Git qanday ishlaydi?](#how-does-git-work)
+ - [Git merge va Git rebase](#git-merge-vs-git-rebase)
+- [Bulutli xizmatlar](#cloud-services)
+ - [Turli xil bulut xizmatlarining chiroyli cheat varag'i (2023 yil nashri)](#a-nice-cheat-sheet-of-different-cloud-services-2023-edition)
+ - [Mahalliy bulut nima?](#what-is-cloud-native)
+- [Ishlab chiquvchi mahsuldorlik vositalari](#developer-productivity-tools)
+ - [JSON fayllarini vizualizatsiya qilish](#visualize-json-files)
+ - [Kodni avtomatik ravishda arxitektura diagrammalariga aylantiring](#automatically-turn-code-into-architecture-diagrams)
+- [Linux](#linux)
+ - [Linux fayl tizimi tushuntirildi](#linux-file-system-explained)
+ - [Siz bilishingiz kerak bo'lgan 18 ta eng ko'p ishlatiladigan Linux buyruqlari](#18-most-used-linux-commands-you-should-know)
+- [Xavfsizlik](#security)
+ - [HTTPS qanday ishlaydi?](#how-does-https-work)
+ - [Oauth 2.0 oddiy shartlar bilan tushuntirilgan.](#oauth-20-explained-with-simple-terms)
+ - [Autentifikatsiya mexanizmlarining 4 ta eng yaxshi shakllari](#top-4-forms-of-authentication-mechanisms)
+ - [Sessiya, cookie, JWT, token, SSO va OAuth 2.0 - ular nima?](#session-cookie-jwt-token-sso-and-oauth-20---what-are-they)
+ - [Ma'lumotlar bazasida parollarni qanday xavfsiz saqlash va parolni qanday tekshirish mumkin?](#how-to-store-passwords-safely-in-the-database-and-how-to-validate-a-password)
+ - [10 yoshli bolaga JSON Web Token (JWT) haqida tushuntirish](#explaining-json-web-token-jwt-to-a-10-year-old-kid)
+ - [Google Authenticator (yoki 2 faktorli autentifikatsiyaning boshqa turlari) qanday ishlaydi?](#how-does-google-authenticator-or-other-types-of-2-factor-authenticators-work)
+- [Haqiqiy dunyo misollari](#real-world-case-studies)
+ - [Netflixning Tech Stacki](#netflixs-tech-stack)
+ - [Twitter arxitekturasi 2022](#twitter-architecture-2022)
+ - [Oxirgi 15 yil ichida Airbnb mikroservis arxitekturasining evolyutsiyasi](#evolution-of-airbnbs-microservice-architecture-over-the-past-15-years)
+ - [Monorepo va mikrorepo.](#monorepo-vs-microrepo)
+ - [Stack Overflow veb-saytini qanday loyihalashtirasiz?](#how-will-you-design-the-stack-overflow-website)
+ - [Nima uchun Amazon Prime Video monitoringi serversizdan monolitga o'tdi? Qanday qilib 90% xarajatlarni tejash mumkin?](#why-did-amazon-prime-video-monitoring-move-from-serverless-to-monolithic-how-can-it-save-90-cost)
+ - [Disney Hotstar turnir davomida 5 milliard kulgichni qanday suratga oladi?](#how-does-disney-hotstar-capture-5-billion-emojis-during-a-tournament)
+ - [Discord qanday qilib trillionlab xabarlarni saqlaydi](#how-discord-stores-trillions-of-messages)
+ - [YouTube, TikTok live yoki Twitch-da jonli video oqimlari qanday ishlaydi?](#how-do-video-live-streamings-work-on-youtube-tiktok-live-or-twitch)
+
+
+
+## Aloqa protokollari
+
+Arxitektura uslublari amaliy dasturlash interfeysining (API) turli komponentlari bir-biri bilan qanday o'zaro ta'sir qilishini belgilaydi.Natijada, ular API-larni loyihalash va qurishda standart yondashuvni ta'minlash orqali samaradorlik, ishonchlilik va boshqa tizimlar bilan integratsiya qulayligini ta'minlaydi. Bu erda eng ko'p ishlatiladigan uslublar:
+
+
+ 
+
+
+- SOAP:
+
+ Yetuk, keng qamrovli, XML-ga asoslangan
+
+ Korporativ ilovalar uchun eng yaxshi
+
+- RESTful:
+
+ Ommabop, amalga oshirish oson, HTTP usullari
+
+ Veb-xizmatlar uchun ideal
+
+- GraphQL:
+
+ So'rov tili, maxsus ma'lumotlarni so'rash
+
+ Tarmoq yukini kamaytiradi, tezroq javob beradi
+
+- gRPC:
+
+ Zamonaviy, yuqori samarali, protokol buferlari
+
+ Mikroservislar arxitekturasi uchun javob beradi
+
+- WebSocket:
+
+ Real-time, bidirectional, persistent connections
+
+ Kam kechikishli ma'lumotlar almashinuvi uchun juda mos keladi
+
+- Webhook:
+
+ Voqealarga asoslangan, HTTP qo'ng'iroqlari, asinxron
+
+ Voqea sodir bo'lganda tizimlarni xabardor qiladi
+
+
+### REST API va GraphQL
+
+API dizayni haqida gap ketganda, REST va GraphQL har birining kuchli va zaif tomonlari bor.
+
+Quyidagi diagrammada REST va GraphQL o'rtasidagi tezkor taqqoslash ko'rsatilgan.
+
+
+ 
+
+
+REST
+
+- CRUD operatsiyalari uchun GET, POST, PUT, DELETE kabi standart HTTP usullaridan foydalanadi.
+- Alohida xizmatlar/ilovalar o'rtasida oddiy, bir xil interfeyslar kerak bo'lganda yaxshi ishlaydi.
+- Keshlash strategiyalarini amalga oshirish oson.
+- Salbiy tomoni shundaki, u alohida so'nggi nuqtalardan tegishli ma'lumotlarni yig'ish uchun bir nechta aylanishlarni talab qilishi mumkin.
+
+GraphQL
+
+- Mijozlarga kerakli ma'lumotlarni aniq so'rashlari uchun yagona so'nggi nuqtani taqdim etadi.
+- Mijozlar ichki so'rovlarda talab qilinadigan aniq maydonlarni belgilaydi va server faqat shu maydonlarni o'z ichiga olgan optimallashtirilgan foydali yuklarni qaytaradi.
+- Ma'lumotlarni o'zgartirish uchun mutatsiyalarni va real vaqtda bildirishnomalar uchun obunalarni qo'llab-quvvatlaydi.
+- Bir nechta manbalardan ma'lumotlarni jamlash uchun ajoyib va tez rivojlanayotgan frontend talablari bilan yaxshi ishlaydi.
+- Biroq, u murakkablikni mijoz tomoniga o'tkazadi va agar to'g'ri himoyalanmagan bo'lsa, haqoratli so'rovlarga ruxsat berishi mumkin.
+- Keshlash strategiyalari RESTga qaraganda murakkabroq bo'lishi mumkin.
+
+REST va GraphQL o'rtasidagi eng yaxshi tanlov dastur va ishlab chiqish guruhining o'ziga xos talablariga bog'liq. GraphQL murakkab yoki tez-tez o'zgaruvchan frontend ehtiyojlari uchun juda mos keladi, REST esa oddiy va izchil shartnomalar afzal ko'rilgan ilovalarga mos keladi.
+
+Hech bir API yondashuvi kumush o'q emas. To'g'ri uslubni tanlash uchun talablar va kelishuvlarni diqqat bilan baholash muhimdir. REST va GraphQL ikkalasi ham ma'lumotlarni oshkor qilish va zamonaviy ilovalarni quvvatlantirish uchun to'g'ri tanlovdir.
+
+
+### gRPC qanday ishlaydi?
+
+RPC (Remote Procedure Call) "**remote(masofaviy)**" deb nomlanadi, chunki u xizmatlar mikroservis arxitekturasi ostida turli serverlarga o'rnatilganda masofaviy xizmatlar o'rtasida aloqa o'rnatish imkonini beradi. Foydalanuvchi nuqtai nazaridan, u mahalliy funktsiya chaqiruvi kabi ishlaydi.
+
+Quyidagi diagramma **gRPC** uchun umumiy ma'lumotlar oqimini ko'rsatadi.
+
+
+ 
+
+
+1-qadam: REST qo'ng'irog'i mijozdan amalga oshiriladi. So'rovning asosiy qismi odatda JSON formatida bo'ladi.
+
+2-4-qadamlar: Buyurtma xizmati (gRPC mijozi) REST qo'ng'irog'ini qabul qiladi, uni o'zgartiradi va to'lov xizmatiga RPC qo'ng'irog'ini qiladi. gRPC **client stub(mijoz stubi)** ni ikkilik formatga kodlaydi va uni past darajadagi transport qatlamiga yuboradi.
+
+5-qadam: gRPC paketlarni HTTP2 orqali tarmoq orqali yuboradi. Ikkilik kodlash va tarmoqni optimallashtirish tufayli gRPC JSONga qaraganda 5X tezroq deb aytiladi.
+
+6-8-qadamlar: Toʻlov xizmati (gRPC serveri) tarmoqdan paketlarni qabul qiladi, ularni dekodlaydi va server ilovasini ishga tushiradi.
+
+9-11-qadamlar: Natija server ilovasidan qaytariladi va kodlanadi va transport qatlamiga yuboriladi.
+
+12-14-qadamlar: Buyurtma xizmati paketlarni qabul qiladi, ularni dekodlaydi va natijani mijoz ilovasiga yuboradi.
+
+### Webhook nima?
+
+Quyidagi diagrammada so'rov va Webhook o'rtasidagi taqqoslash ko'rsatilgan.
+
+
+ 
+
+
+Faraz qilaylik, biz elektron tijorat veb-saytini ishga tushiramiz. Mijozlar to'lov operatsiyalari uchun to'lov xizmatiga o'tadigan API shlyuzi orqali buyurtma xizmatiga buyurtma yuboradilar. Keyin to'lov xizmati tranzaktsiyalarni bajarish uchun tashqi to'lov xizmati provayderi (PSP) bilan gaplashadi.
+
+Tashqi PSP bilan aloqa qilishning ikki yo'li mavjud.
+
+**1. Short polling(Qisqa ovoz berish)**
+
+To'lov so'rovi PSP ga yuborilgandan so'ng, to'lov xizmati PSP dan to'lov holati haqida so'rashda davom etadi. Bir necha turdan so'ng, PSP nihoyat holatga qaytadi.
+
+Qisqa so'rovning ikkita kamchiligi bor:
+* Doimiy ravishda vaziyatni so'rash to'lov xizmatidan resurslarni talab qiladi.
+* Tashqi xizmat to'lov xizmati bilan to'g'ridan-to'g'ri bog'lanib, xavfsizlik zaifliklarini yaratadi.
+
+**2. Webhook**
+
+Biz webhukni tashqi xizmatda ro'yxatdan o'tkazishimiz mumkin. Buning ma'nosi: so'rov bo'yicha yangilanishlar mavjud bo'lganda, menga ma'lum bir URL orqali qo'ng'iroq qiling. PSP qayta ishlashni tugatgandan so'ng, to'lov holatini yangilash uchun HTTP so'rovini chaqiradi.
+
+Shu tarzda, dasturlash paradigmasi o'zgartiriladi va to'lov xizmati endi to'lov holatini so'rash uchun resurslarni isrof qilishiga hojat yo'q.
+
+Agar PSP hech qachon qo'ng'iroq qilmasa nima bo'ladi? Biz har soatda to'lov holatini tekshirish uchun uy ishlarini o'rnatishimiz mumkin.
+
+WebhooksWebhuklar ko'pincha teskari API yoki push API deb ataladi, chunki server mijozga HTTP so'rovlarini yuboradi. Webhukdan foydalanishda 3 narsaga e'tibor qaratishimiz kerak:
+
+1. Biz tashqi xizmat qo'ng'iroq qilish uchun tegishli APIni loyihalashimiz kerak.
+2. Xavfsizlik nuqtai nazaridan API shlyuzida tegishli qoidalarni o'rnatishimiz kerak.
+3. Biz tashqi xizmatda to'g'ri URL manzilini ro'yxatdan o'tkazishimiz kerak.
+
+### API ish faoliyatini qanday yaxshilash mumkin?
+
+Quyidagi diagrammada API ish faoliyatini yaxshilash uchun 5 ta umumiy hiyla ko'rsatilgan.
+
+
+ 
+
+
+Pagination(Sahifalar)
+
+Natijaning o'lchami katta bo'lsa, bu keng tarqalgan optimallashtirishdir. Natijalar xizmatning javob berish qobiliyatini yaxshilash uchun mijozga qaytariladi.
+
+Asynchronous Logging(Asinxron ro'yxatga olish)
+
+Sinxron ro'yxatga olish har bir qo'ng'iroq uchun disk bilan ishlaydi va tizimni sekinlashtirishi mumkin. Asinxron ro'yxatga olish jurnallarni avval qulflanmagan buferga yuboradi va darhol qaytadi. Jurnallar diskka vaqti-vaqti bilan tozalanadi. Bu kiritish-chiqarish xarajatlarini sezilarli darajada kamaytiradi.
+
+Caching(Keshlash)
+
+Biz tez-tez foydalaniladigan ma'lumotlarni keshga saqlashimiz mumkin. Mijoz to'g'ridan-to'g'ri ma'lumotlar bazasiga tashrif buyurish o'rniga, avval keshni so'rashi mumkin. Agar kesh o'tkazib yuborilgan bo'lsa, mijoz ma'lumotlar bazasidan so'rashi mumkin. Redis kabi keshlar ma'lumotlarni xotirada saqlaydi, shuning uchun ma'lumotlarga kirish ma'lumotlar bazasiga qaraganda ancha tezroq.
+
+Payload Compression(Yuk yukini siqish)
+
+So'rovlar va javoblar uzatiladigan ma'lumotlar hajmi ancha kichik bo'lishi uchun gzip va boshqalar yordamida siqilishi mumkin. Bu yuklash va yuklab olishni tezlashtiradi.
+
+Connection Pool(Aloqa hovuzi)
+
+Resurslarga kirishda biz ko'pincha ma'lumotlar bazasidan ma'lumotlarni yuklashimiz kerak. Yopuvchi db ulanishlarini ochish sezilarli yukni oshiradi. Shunday qilib, biz DB ga ochiq ulanishlar hovuzi orqali ulanishimiz kerak. Ulanish havzasi ulanishning hayot aylanishini boshqarish uchun javobgardir.
+
+### HTTP 1.0 -> HTTP 1.1 -> HTTP 2.0 -> HTTP 3.0 (QUIC)
+
+HTTP ning har bir avlodi qanday muammoni hal qiladi?
+
+Quyidagi diagrammada asosiy xususiyatlar ko'rsatilgan.
+
+
+ 
+
+
+- HTTP 1.0 1996 yilda yakunlangan va to'liq hujjatlashtirilgan. Bitta serverga har bir so'rov alohida TCP ulanishini talab qiladi.
+
+- HTTP 1.1 1997 yilda nashr etilgan. TCP ulanishi qayta foydalanish uchun ochiq qoldirilishi mumkin (doimiy ulanish), lekin bu HOL (yo'nalish boshi(head-of-line)) blokirovkasi muammosini hal qilmaydi.
+
+ HOL blokirovkasi - brauzerda ruxsat etilgan parallel so'rovlar soni tugaganda, keyingi so'rovlar avvalgilarining bajarilishini kutishlari kerak.
+
+- HTTP 2.0 2015-yilda nashr etilgan. U HOL muammosini soʻrovni multiplekslash orqali hal qiladi, bu esa dastur qatlamida HOL bloklanishini bartaraf qiladi, biroq HOL transport (TCP) qatlamida hali ham mavjud.
+
+ Diagrammada ko'rib turganingizdek, HTTP 2.0 HTTP "oqimlari" tushunchasini taqdim etdi: bir xil TCP ulanishiga turli xil HTTP almashinuvlarini multiplekslash imkonini beruvchi abstraksiya. Har bir oqimni tartibda yuborish shart emas.
+
+- HTTP 3.0 ning birinchi loyihasi 2020-yilda chop etilgan. U HTTP 2.0 ning tavsiya etilgan vorisi hisoblanadi. U asosiy transport protokoli uchun TCP o'rniga QUIC dan foydalanadi, shuning uchun transport qatlamidagi HOL blokirovkasini olib tashlaydi.
+
+QUIC UDP ga asoslangan. U oqimlarni transport qatlamida birinchi darajali fuqarolar sifatida tanishtiradi. QUIC oqimlari bir xil QUIC ulanishiga ega, shuning uchun yangilarini yaratish uchun qo'shimcha qo'l siqish(handshake) va sekin boshlash(slow start) talab qilinmaydi, lekin QUIC oqimlari mustaqil ravishda yetkazib beriladi, ko'p hollarda bitta oqimga ta'sir qiladigan paket yo'qotilishi boshqalarga ta'sir qilmaydi.
+
+### SOAP va REST va GraphQL va RPC
+
+Quyidagi diagrammada API vaqt jadvali va API uslublarini taqqoslash tasvirlangan.
+
+Vaqt o'tishi bilan turli xil API arxitektura uslublari chiqariladi. Ularning har biri ma'lumotlar almashinuvini standartlashtirishning o'ziga xos naqshlariga ega.
+
+Diagrammada har bir uslubning foydalanish holatlarini tekshirishingiz mumkin.
+
+
+ 
+
+
+
+### Code First va API First
+
+Quyidagi diagrammada birinchi kodni ishlab chiqish va API-birinchi ishlanma o'rtasidagi farqlar ko'rsatilgan. Nima uchun biz API birinchi dizaynini ko'rib chiqmoqchimiz?
+
+
+ 
+
+
+
+- Mikroservislar tizimning murakkabligini oshiradi va bizda tizimning turli funktsiyalarini bajarish uchun alohida xizmatlar mavjud. Ushbu turdagi arxitektura vazifalarni ajratish va ajratishni osonlashtirsa-da, biz xizmatlar o'rtasidagi turli xil aloqalarni boshqarishimiz kerak.
+
+Kodni yozishdan va xizmatlar chegaralarini sinchkovlik bilan belgilashdan oldin tizimning murakkabligini o'ylab ko'rgan ma'qul.
+
+- Alohida funktsional guruhlar bir xil tilda gapirishlari kerak va maxsus funktsional guruhlar faqat o'zlarining tarkibiy qismlari va xizmatlari uchun javobgardir. Tashkilotga API dizayni orqali bir xil tilda gapirish tavsiya etiladi.
+
+Kod yozishdan oldin API dizaynini tasdiqlash uchun so'rovlar va javoblarni masxara qilishimiz mumkin.
+
+- Dasturiy ta'minot sifati va ishlab chiquvchining mahsuldorligini oshirish Loyiha boshlanganda noaniqliklarning ko'pini bartaraf etganimiz sababli, umumiy ishlab chiqish jarayoni yanada silliqlashadi va dasturiy ta'minot sifati sezilarli darajada yaxshilanadi.
+
+Ishlab chiquvchilar ham jarayondan xursandlar, chunki ular to'satdan o'zgarishlarni muhokama qilish o'rniga funktsional rivojlanishga e'tibor berishlari mumkin.
+
+Loyihaning hayotiy tsiklining oxiriga kelib kutilmagan hodisalar bo'lish ehtimoli kamayadi.
+
+Biz APIni birinchi bo'lib ishlab chiqqanimiz sababli, testlar kod ishlab chiqilayotganda ishlab chiqilishi mumkin. Qaysidir ma'noda, API birinchi ishlanmasidan foydalanganda bizda TDD (Test Driven Design) mavjud.
+
+### HTTP holat kodlari
+
+
+ 
+
+
+
+HTTP uchun javob kodlari besh toifaga bo'lingan:
+
+Informational (100-199) \
+Success (200-299) \
+Redirection (300-399) \
+Client Error (400-499) \
+Server Error (500-599)
+
+### API shlyuzi nima qiladi?
+
+Quyidagi diagrammada tafsilotlar ko'rsatilgan.
+
+
+ 
+
+
+1-qadam - mijoz API shlyuziga HTTP so'rovini yuboradi.
+
+2-qadam - API shlyuzi HTTP so'rovidagi atributlarni tahlil qiladi va tasdiqlaydi.
+
+3-qadam - API shlyuzi ruxsat-roʻyxat/rad etish roʻyxatini tekshirishni amalga oshiradi.
+
+4-qadam - API shlyuzi autentifikatsiya va avtorizatsiya uchun identifikatsiya provayderi bilan gaplashadi.
+
+5-qadam - so'rovga tarifni cheklash qoidalari qo'llaniladi. Agar limitdan oshib ketgan bo'lsa, so'rov rad etiladi.
+
+6 va 7-qadamlar - Endi so'rov asosiy tekshiruvlardan o'tgan bo'lsa, API shlyuzi mos keladigan yo'nalish bo'yicha yo'nalish uchun tegishli xizmatni topadi.
+
+8-qadam - API shlyuzi so'rovni tegishli protokolga o'zgartiradi va uni backend mikroservislariga yuboradi.
+
+9-12-qadamlar: API shlyuzi xatolarni to'g'ri boshqarishi mumkin va agar xatoni tiklash uchun ko'proq vaqt kerak bo'lsa, xatolar bilan shug'ullanadi (elektron uzilish). Shuningdek, u ro'yxatga olish va monitoring qilish uchun ELK (Elastic-Logstash-Kibana) stekidan foydalanishi mumkin. Biz ba'zan ma'lumotlarni API shlyuzida keshlaymiz.
+
+### Qanday qilib samarali va xavfsiz API-larni loyihalashtiramiz?
+
+Quyidagi diagrammada xarid savatchasi misoli bilan odatiy API dizaynlari ko'rsatilgan.
+
+
+ 
+
+
+
+E'tibor bering, API dizayni shunchaki URL yo'l dizayni emas. Ko'pincha biz to'g'ri manba nomlarini, identifikatorlarni va yo'l naqshlarini tanlashimiz kerak. Tegishli HTTP sarlavhalari maydonlarini loyihalash yoki API shlyuzida samarali tezlikni cheklovchi qoidalarni ishlab chiqish bir xil darajada muhimdir.
+
+### TCP/IP inkapsulyatsiyasi
+
+Ma'lumotlar tarmoq orqali qanday uzatiladi? Nima uchun bizga OSI modelida juda ko'p qatlamlar kerak?
+
+
+ 
+
+
+Quyidagi diagrammada tarmoq orqali uzatishda ma'lumotlarning qanday inkapsullanganligi va inkapsulatsiyasi ko'rsatilgan.
+
+1-qadam: A qurilmasi HTTP protokoli orqali tarmoq orqali B qurilmaga ma'lumotlarni yuborganda, u birinchi navbatda dastur sathida HTTP sarlavhasi qo'shiladi.
+
+2-qadam: Keyin ma'lumotlarga TCP yoki UDP sarlavhasi qo'shiladi. U transport qatlamida TCP segmentlariga inkapsullangan. Sarlavhada manba porti, maqsad porti va tartib raqami mavjud.
+
+3-qadam: Keyin segmentlar tarmoq sathida IP sarlavhasi bilan qoplangan. IP sarlavhasi manba/maqsad IP manzillarini o'z ichiga oladi.
+
+4-qadam: IP-datagramma manba/maqsad MAC manzillari bilan ma'lumotlar havolasi qatlamiga MAC sarlavhasi qo'shiladi.
+
+5-qadam: Inkapsullangan ramkalar jismoniy qatlamga yuboriladi va tarmoq orqali ikkilik bitlarda yuboriladi.
+
+6-10-qadamlar: B qurilmasi tarmoqdan bitlarni qabul qilganda, u inkapsulyatsiya jarayonining teskari ishlovi bo'lgan de-kapsulyatsiya jarayonini amalga oshiradi. Sarlavhalar qavatma-qavat o'chiriladi va oxir-oqibat B qurilmasi ma'lumotlarni o'qiy oladi.
+
+Tarmoq modelida qatlamlar kerak, chunki har bir qatlam o'z mas'uliyatiga e'tibor qaratadi. Har bir qatlam ko'rsatmalarni qayta ishlash uchun sarlavhalarga tayanishi mumkin va oxirgi qatlamdagi ma'lumotlarning ma'nosini bilish shart emas.
+
+### Nima uchun Nginx "teskari" proksi-server deb ataladi?
+
+Quyidagi diagrammada 𝐟𝐨𝐫𝐰𝐚𝐫𝐝 𝐩𝐫𝐨𝐱𝐲 va 𝐫𝐞𝐯𝐞𝐫𝐬𝐞 𝐩𝐱𝐨 oʻrtasidagi farqlar koʻrsatilgan.
+
+
+ 
+
+
+Oldinga proksi-server foydalanuvchi qurilmalari va internet o'rtasida joylashgan serverdir.
+
+Proksi-server odatda quyidagilar uchun ishlatiladi:
+
+1. Mijozlarni himoya qilish
+2. Ko'rib chiqish cheklovlarini chetlab o'tish
+3. Muayyan tarkibga kirishni bloklash
+
+Teskari proksi-server mijozning so'rovini qabul qiladigan, so'rovni veb-serverlarga yo'naltiradigan va proksi-server so'rovni qayta ishlagandek natijalarni mijozga qaytaradigan serverdir.
+
+Teskari proksi-server quyidagilar uchun mos keladi:
+
+1. Serverlarni himoya qilish
+2. Yukni muvozanatlash
+3. Statik tarkibni keshlash
+4. SSL aloqalarini shifrlash va shifrini ochish
+
+### Umumiy yuklarni muvozanatlash algoritmlari qanday?
+
+Quyidagi diagrammada 6 ta umumiy algoritm ko'rsatilgan.
+
+
+ 
+
+
+- Statik Algoritmlar
+
+1. Aylanma o'yin(Round robin)
+
+ Mijoz so'rovlari turli xil xizmat ko'rsatish instantsiyalariga ketma-ket tartibda yuboriladi. Xizmatlar odatda fuqaroligi bo'lmagan bo'lishi kerak.
+
+2. Yopishqoq aylanma-robin (Sticky round-robin)
+
+ Bu round-robin algoritmini takomillashtirishdir. Agar Elisning birinchi so'rovi A xizmatiga kirsa, keyingi so'rovlar ham A xizmatiga o'tadi.
+
+3. Og'irlangan aylanma-robin (Weighted round-robin)
+
+ Administrator har bir xizmat uchun vaznni belgilashi mumkin. Og'irligi yuqori bo'lganlar boshqalarga qaraganda ko'proq so'rovlarni qabul qilishadi.
+
+4. Hesh
+
+ Ushbu algoritm kiruvchi so'rovlarning IP yoki URL manzilida xesh funktsiyasini qo'llaydi. So'rovlar xesh funksiyasi natijasi asosida tegishli instansiyalarga yo'naltiriladi.
+
+- Dinamik Algoritmlar
+
+5. Eng kam ulanishlar
+
+ Eng kam parallel ulanishlar bilan xizmat ko'rsatish instantsiyasiga yangi so'rov yuboriladi.
+
+6. Eng kam javob vaqti
+
+ Yangi so'rov eng tez javob vaqti bilan xizmat instantsiyasiga yuboriladi.
+
+### URL, URI, URN - Farqlarni bilasizmi?
+
+Quyidagi diagrammada URL, URI va URN solishtirish ko'rsatilgan.
+
+
+ 
+
+
+- URI
+
+URI yagona resurs identifikatorini (Uniform Resource Identifier) anglatadi. U internetdagi mantiqiy yoki jismoniy manbani aniqlaydi. URL va URN URI ning pastki turlaridir. URL manbani aniqlaydi, URN esa resurs nomini beradi.
+
+URI quyidagi qismlardan iborat:
+scheme:[//authority]path[?query][#fragment]
+
+- URL
+
+URL HTTP ning asosiy tushunchasi bo'lgan Yagona Resurs Locator (Uniform Resource Locator) degan ma'noni anglatadi. Bu internetdagi noyob manbaning manzili. U FTP va JDBC kabi boshqa protokollar bilan ishlatilishi mumkin.
+
+- URN
+
+URN yagona manba nomini (Uniform Resource Name) anglatadi. U urn sxemasidan foydalanadi. Resursni topish uchun URN-lardan foydalanib bo'lmaydi. Diagrammada keltirilgan oddiy misol nomlar maydoni va nomlar maydoniga xos qatordan iborat.
+
+Agar siz ushbu mavzu bo'yicha batafsil ma'lumot olishni istasangiz, men [W3C'ning tushuntirishini](https://www.w3.org/TR/uri-clarification/) tavsiya qilaman.
+
+## CI/CD
+
+### CI/CD Pipeline Explained in Simple Terms
+
+
+ 
+
+
+Section 1 - SDLC with CI/CD
+
+The software development life cycle (SDLC) consists of several key stages: development, testing, deployment, and maintenance. CI/CD automates and integrates these stages to enable faster and more reliable releases.
+
+When code is pushed to a git repository, it triggers an automated build and test process. End-to-end (e2e) test cases are run to validate the code. If tests pass, the code can be automatically deployed to staging/production. If issues are found, the code is sent back to development for bug fixing. This automation provides fast feedback to developers and reduces the risk of bugs in production.
+
+Section 2 - Difference between CI and CD
+
+Continuous Integration (CI) automates the build, test, and merge process. It runs tests whenever code is committed to detect integration issues early. This encourages frequent code commits and rapid feedback.
+
+Continuous Delivery (CD) automates release processes like infrastructure changes and deployment. It ensures software can be released reliably at any time through automated workflows. CD may also automate the manual testing and approval steps required before production deployment.
+
+Section 3 - CI/CD Pipeline
+
+A typical CI/CD pipeline has several connected stages:
+- The developer commits code changes to the source control
+- CI server detects changes and triggers the build
+- Code is compiled, and tested (unit, integration tests)
+- Test results reported to the developer
+- On success, artifacts are deployed to staging environments
+- Further testing may be done on staging before release
+- CD system deploys approved changes to production
+
+### Netflix Tech Stack (CI/CD Pipeline)
+
+
+ 
+
+
+Planning: Netflix Engineering uses JIRA for planning and Confluence for documentation.
+
+Coding: Java is the primary programming language for the backend service, while other languages are used for different use cases.
+
+Build: Gradle is mainly used for building, and Gradle plugins are built to support various use cases.
+
+Packaging: Package and dependencies are packed into an Amazon Machine Image (AMI) for release.
+
+Testing: Testing emphasizes the production culture's focus on building chaos tools.
+
+Deployment: Netflix uses its self-built Spinnaker for canary rollout deployment.
+
+Monitoring: The monitoring metrics are centralized in Atlas, and Kayenta is used to detect anomalies.
+
+Incident report: Incidents are dispatched according to priority, and PagerDuty is used for incident handling.
+
+## Architecture patterns
+
+### MVC, MVP, MVVM, MVVM-C, and VIPER
+These architecture patterns are among the most commonly used in app development, whether on iOS or Android platforms. Developers have introduced them to overcome the limitations of earlier patterns. So, how do they differ?
+
+
+ 
+
+
+- MVC, the oldest pattern, dates back almost 50 years
+- Every pattern has a "view" (V) responsible for displaying content and receiving user input
+- Most patterns include a "model" (M) to manage business data
+- "Controller," "presenter," and "view-model" are translators that mediate between the view and the model ("entity" in the VIPER pattern)
+
+### 18 Key Design Patterns Every Developer Should Know
+
+Patterns are reusable solutions to common design problems, resulting in a smoother, more efficient development process. They serve as blueprints for building better software structures. These are some of the most popular patterns:
+
+
+ 
+
+
+- Abstract Factory: Family Creator - Makes groups of related items.
+- Builder: Lego Master - Builds objects step by step, keeping creation and appearance separate.
+- Prototype: Clone Maker - Creates copies of fully prepared examples.
+- Singleton: One and Only - A special class with just one instance.
+- Adapter: Universal Plug - Connects things with different interfaces.
+- Bridge: Function Connector - Links how an object works to what it does.
+- Composite: Tree Builder - Forms tree-like structures of simple and complex parts.
+- Decorator: Customizer - Adds features to objects without changing their core.
+- Facade: One-Stop-Shop - Represents a whole system with a single, simplified interface.
+- Flyweight: Space Saver - Shares small, reusable items efficiently.
+- Proxy: Stand-In Actor - Represents another object, controlling access or actions.
+- Chain of Responsibility: Request Relay - Passes a request through a chain of objects until handled.
+- Command: Task Wrapper - Turns a request into an object, ready for action.
+- Iterator: Collection Explorer - Accesses elements in a collection one by one.
+- Mediator: Communication Hub - Simplifies interactions between different classes.
+- Memento: Time Capsule - Captures and restores an object's state.
+- Observer: News Broadcaster - Notifies classes about changes in other objects.
+- Visitor: Skillful Guest - Adds new operations to a class without altering it.
+
+## Database
+
+### A nice cheat sheet of different databases in cloud services
+
+
+ 
+
+
+Choosing the right database for your project is a complex task. Many database options, each suited to distinct use cases, can quickly lead to decision fatigue.
+
+We hope this cheat sheet provides high-level direction to pinpoint the right service that aligns with your project's needs and avoid potential pitfalls.
+
+Note: Google has limited documentation for their database use cases. Even though we did our best to look at what was available and arrived at the best option, some of the entries may need to be more accurate.
+
+### 8 Data Structures That Power Your Databases
+
+The answer will vary depending on your use case. Data can be indexed in memory or on disk. Similarly, data formats vary, such as numbers, strings, geographic coordinates, etc. The system might be write-heavy or read-heavy. All of these factors affect your choice of database index format.
+
+
+ 
+
+
+The following are some of the most popular data structures used for indexing data:
+
+- Skiplist: a common in-memory index type. Used in Redis
+- Hash index: a very common implementation of the “Map” data structure (or “Collection”)
+- SSTable: immutable on-disk “Map” implementation
+- LSM tree: Skiplist + SSTable. High write throughput
+- B-tree: disk-based solution. Consistent read/write performance
+- Inverted index: used for document indexing. Used in Lucene
+- Suffix tree: for string pattern search
+- R-tree: multi-dimension search, such as finding the nearest neighbor
+
+### How is an SQL statement executed in the database?
+
+The diagram below shows the process. Note that the architectures for different databases are different, the diagram demonstrates some common designs.
+
+
+ 
+
+
+
+Step 1 - A SQL statement is sent to the database via a transport layer protocol (e.g.TCP).
+
+Step 2 - The SQL statement is sent to the command parser, where it goes through syntactic and semantic analysis, and a query tree is generated afterward.
+
+Step 3 - The query tree is sent to the optimizer. The optimizer creates an execution plan.
+
+Step 4 - The execution plan is sent to the executor. The executor retrieves data from the execution.
+
+Step 5 - Access methods provide the data fetching logic required for execution, retrieving data from the storage engine.
+
+Step 6 - Access methods decide whether the SQL statement is read-only. If the query is read-only (SELECT statement), it is passed to the buffer manager for further processing. The buffer manager looks for the data in the cache or data files.
+
+Step 7 - If the statement is an UPDATE or INSERT, it is passed to the transaction manager for further processing.
+
+Step 8 - During a transaction, the data is in lock mode. This is guaranteed by the lock manager. It also ensures the transaction’s ACID properties.
+
+### CAP theorem
+
+The CAP theorem is one of the most famous terms in computer science, but I bet different developers have different understandings. Let’s examine what it is and why it can be confusing.
+
+
+ 
+
+
+CAP theorem states that a distributed system can't provide more than two of these three guarantees simultaneously.
+
+**Consistency**: consistency means all clients see the same data at the same time no matter which node they connect to.
+
+**Availability**: availability means any client that requests data gets a response even if some of the nodes are down.
+
+**Partition Tolerance**: a partition indicates a communication break between two nodes. Partition tolerance means the system continues to operate despite network partitions.
+
+The “2 of 3” formulation can be useful, **but this simplification could be misleading**.
+
+1. Picking a database is not easy. Justifying our choice purely based on the CAP theorem is not enough. For example, companies don't choose Cassandra for chat applications simply because it is an AP system. There is a list of good characteristics that make Cassandra a desirable option for storing chat messages. We need to dig deeper.
+
+2. “CAP prohibits only a tiny part of the design space: perfect availability and consistency in the presence of partitions, which are rare”. Quoted from the paper: CAP Twelve Years Later: How the “Rules” Have Changed.
+
+3. The theorem is about 100% availability and consistency. A more realistic discussion would be the trade-offs between latency and consistency when there is no network partition. See PACELC theorem for more details.
+
+**Is the CAP theorem actually useful?**
+
+I think it is still useful as it opens our minds to a set of tradeoff discussions, but it is only part of the story. We need to dig deeper when picking the right database.
+
+### Types of Memory and Storage
+
+
+ 
+
+
+
+### Visualizing a SQL query
+
+
+ 
+
+
+SQL statements are executed by the database system in several steps, including:
+
+- Parsing the SQL statement and checking its validity
+- Transforming the SQL into an internal representation, such as relational algebra
+- Optimizing the internal representation and creating an execution plan that utilizes index information
+- Executing the plan and returning the results
+
+The execution of SQL is highly complex and involves many considerations, such as:
+
+- The use of indexes and caches
+- The order of table joins
+- Concurrency control
+- Transaction management
+
+### SQL language
+
+In 1986, SQL (Structured Query Language) became a standard. Over the next 40 years, it became the dominant language for relational database management systems. Reading the latest standard (ANSI SQL 2016) can be time-consuming. How can I learn it?
+
+
+ 
+
+
+There are 5 components of the SQL language:
+
+- DDL: data definition language, such as CREATE, ALTER, DROP
+- DQL: data query language, such as SELECT
+- DML: data manipulation language, such as INSERT, UPDATE, DELETE
+- DCL: data control language, such as GRANT, REVOKE
+- TCL: transaction control language, such as COMMIT, ROLLBACK
+
+For a backend engineer, you may need to know most of it. As a data analyst, you may need to have a good understanding of DQL. Select the topics that are most relevant to you.
+
+## Cache
+
+### Data is cached everywhere
+
+This diagram illustrates where we cache data in a typical architecture.
+
+
+ 
+
+
+
+There are **multiple layers** along the flow.
+
+1. Client apps: HTTP responses can be cached by the browser. We request data over HTTP for the first time, and it is returned with an expiry policy in the HTTP header; we request data again, and the client app tries to retrieve the data from the browser cache first.
+2. CDN: CDN caches static web resources. The clients can retrieve data from a CDN node nearby.
+3. Load Balancer: The load Balancer can cache resources as well.
+4. Messaging infra: Message brokers store messages on disk first, and then consumers retrieve them at their own pace. Depending on the retention policy, the data is cached in Kafka clusters for a period of time.
+5. Services: There are multiple layers of cache in a service. If the data is not cached in the CPU cache, the service will try to retrieve the data from memory. Sometimes the service has a second-level cache to store data on disk.
+6. Distributed Cache: Distributed cache like Redis holds key-value pairs for multiple services in memory. It provides much better read/write performance than the database.
+7. Full-text Search: we sometimes need to use full-text searches like Elastic Search for document search or log search. A copy of data is indexed in the search engine as well.
+8. Database: Even in the database, we have different levels of caches:
+- WAL(Write-ahead Log): data is written to WAL first before building the B tree index
+- Bufferpool: A memory area allocated to cache query results
+- Materialized View: Pre-compute query results and store them in the database tables for better query performance
+- Transaction log: record all the transactions and database updates
+- Replication Log: used to record the replication state in a database cluster
+
+### Why is Redis so fast?
+
+There are 3 main reasons as shown in the diagram below.
+
+
+ 
+
+
+
+1. Redis is a RAM-based data store. RAM access is at least 1000 times faster than random disk access.
+2. Redis leverages IO multiplexing and single-threaded execution loop for execution efficiency.
+3. Redis leverages several efficient lower-level data structures.
+
+Question: Another popular in-memory store is Memcached. Do you know the differences between Redis and Memcached?
+
+You might have noticed the style of this diagram is different from my previous posts. Please let me know which one you prefer.
+
+### How can Redis be used?
+
+
+ 
+
+
+
+There is more to Redis than just caching.
+
+Redis can be used in a variety of scenarios as shown in the diagram.
+
+- Session
+
+ We can use Redis to share user session data among different services.
+
+- Cache
+
+ We can use Redis to cache objects or pages, especially for hotspot data.
+
+- Distributed lock
+
+ We can use a Redis string to acquire locks among distributed services.
+
+- Counter
+
+ We can count how many likes or how many reads for articles.
+
+- Rate limiter
+
+ We can apply a rate limiter for certain user IPs.
+
+- Global ID generator
+
+ We can use Redis Int for global ID.
+
+- Shopping cart
+
+ We can use Redis Hash to represent key-value pairs in a shopping cart.
+
+- Calculate user retention
+
+ We can use Bitmap to represent the user login daily and calculate user retention.
+
+- Message queue
+
+ We can use List for a message queue.
+
+- Ranking
+
+ We can use ZSet to sort the articles.
+
+### Top caching strategies
+
+Designing large-scale systems usually requires careful consideration of caching.
+Below are five caching strategies that are frequently utilized.
+
+
+ 
+
+
+
+
+## Microservice architecture
+
+### What does a typical microservice architecture look like?
+
+
+ 
+
+
+
+The diagram below shows a typical microservice architecture.
+
+- Load Balancer: This distributes incoming traffic across multiple backend services.
+- CDN (Content Delivery Network): CDN is a group of geographically distributed servers that hold static content for faster delivery. The clients look for content in CDN first, then progress to backend services.
+- API Gateway: This handles incoming requests and routes them to the relevant services. It talks to the identity provider and service discovery.
+- Identity Provider: This handles authentication and authorization for users.
+- Service Registry & Discovery: Microservice registration and discovery happen in this component, and the API gateway looks for relevant services in this component to talk to.
+- Management: This component is responsible for monitoring the services.
+- Microservices: Microservices are designed and deployed in different domains. Each domain has its own database. The API gateway talks to the microservices via REST API or other protocols, and the microservices within the same domain talk to each other using RPC (Remote Procedure Call).
+
+Benefits of microservices:
+
+- They can be quickly designed, deployed, and horizontally scaled.
+- Each domain can be independently maintained by a dedicated team.
+- Business requirements can be customized in each domain and better supported, as a result.
+
+### Microservice Best Practices
+
+A picture is worth a thousand words: 9 best practices for developing microservices.
+
+
+ 
+
+
+
+When we develop microservices, we need to follow the following best practices:
+
+1. Use separate data storage for each microservice
+2. Keep code at a similar level of maturity
+3. Separate build for each microservice
+4. Assign each microservice with a single responsibility
+5. Deploy into containers
+6. Design stateless services
+7. Adopt domain-driven design
+8. Design micro frontend
+9. Orchestrating microservices
+
+### What tech stack is commonly used for microservices?
+
+Below you will find a diagram showing the microservice tech stack, both for the development phase and for production.
+
+
+ 
+
+
+
+▶️ 𝐏𝐫𝐞-𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧
+
+- Define API - This establishes a contract between frontend and backend. We can use Postman or OpenAPI for this.
+- Development - Node.js or react is popular for frontend development, and java/python/go for backend development. Also, we need to change the configurations in the API gateway according to API definitions.
+- Continuous Integration - JUnit and Jenkins for automated testing. The code is packaged into a Docker image and deployed as microservices.
+
+▶️ 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧
+
+- NGinx is a common choice for load balancers. Cloudflare provides CDN (Content Delivery Network).
+- API Gateway - We can use spring boot for the gateway, and use Eureka/Zookeeper for service discovery.
+- The microservices are deployed on clouds. We have options among AWS, Microsoft Azure, or Google GCP.
+Cache and Full-text Search - Redis is a common choice for caching key-value pairs. Elasticsearch is used for full-text search.
+- Communications - For services to talk to each other, we can use messaging infra Kafka or RPC.
+- Persistence - We can use MySQL or PostgreSQL for a relational database, and Amazon S3 for object store. We can also use Cassandra for the wide-column store if necessary.
+- Management & Monitoring - To manage so many microservices, the common Ops tools include Prometheus, Elastic Stack, and Kubernetes.
+
+### Why is Kafka fast
+
+There are many design decisions that contributed to Kafka’s performance. In this post, we’ll focus on two. We think these two carried the most weight.
+
+
+ 
+
+
+1. The first one is Kafka’s reliance on Sequential I/O.
+2. The second design choice that gives Kafka its performance advantage is its focus on efficiency: zero copy principle.
+
+The diagram illustrates how the data is transmitted between producer and consumer, and what zero-copy means.
+
+- Step 1.1 - 1.3: Producer writes data to the disk
+- Step 2: Consumer reads data without zero-copy
+
+2.1 The data is loaded from disk to OS cache
+
+2.2 The data is copied from OS cache to Kafka application
+
+2.3 Kafka application copies the data into the socket buffer
+
+2.4 The data is copied from socket buffer to network card
+
+2.5 The network card sends data out to the consumer
+
+
+- Step 3: Consumer reads data with zero-copy
+
+3.1: The data is loaded from disk to OS cache
+3.2 OS cache directly copies the data to the network card via sendfile() command
+3.3 The network card sends data out to the consumer
+
+Zero copy is a shortcut to save the multiple data copies between application context and kernel context.
+
+## Payment systems
+
+### How to learn payment systems?
+
+
+ 
+
+
+### Why is the credit card called “the most profitable product in banks”? How does VISA/Mastercard make money?
+
+The diagram below shows the economics of the credit card payment flow.
+
+
+ 
+
+
+1. The cardholder pays a merchant $100 to buy a product.
+
+2. The merchant benefits from the use of the credit card with higher sales volume and needs to compensate the issuer and the card network for providing the payment service. The acquiring bank sets a fee with the merchant, called the “merchant discount fee.”
+
+3 - 4. The acquiring bank keeps $0.25 as the acquiring markup, and $1.75 is paid to the issuing bank as the interchange fee. The merchant discount fee should cover the interchange fee.
+
+ The interchange fee is set by the card network because it is less efficient for each issuing bank to negotiate fees with each merchant.
+
+5. The card network sets up the network assessments and fees with each bank, which pays the card network for its services every month. For example, VISA charges a 0.11% assessment, plus a $0.0195 usage fee, for every swipe.
+
+6. The cardholder pays the issuing bank for its services.
+
+Why should the issuing bank be compensated?
+
+- The issuer pays the merchant even if the cardholder fails to pay the issuer.
+- The issuer pays the merchant before the cardholder pays the issuer.
+- The issuer has other operating costs, including managing customer accounts, providing statements, fraud detection, risk management, clearing & settlement, etc.
+
+### How does VISA work when we swipe a credit card at a merchant’s shop?
+
+
+ 
+
+
+
+VISA, Mastercard, and American Express act as card networks for the clearing and settling of funds. The card acquiring bank and the card issuing bank can be – and often are – different. If banks were to settle transactions one by one without an intermediary, each bank would have to settle the transactions with all the other banks. This is quite inefficient.
+
+The diagram below shows VISA’s role in the credit card payment process. There are two flows involved. Authorization flow happens when the customer swipes the credit card. Capture and settlement flow happens when the merchant wants to get the money at the end of the day.
+
+- Authorization Flow
+
+Step 0: The card issuing bank issues credit cards to its customers.
+
+Step 1: The cardholder wants to buy a product and swipes the credit card at the Point of Sale (POS) terminal in the merchant’s shop.
+
+Step 2: The POS terminal sends the transaction to the acquiring bank, which has provided the POS terminal.
+
+Steps 3 and 4: The acquiring bank sends the transaction to the card network, also called the card scheme. The card network sends the transaction to the issuing bank for approval.
+
+Steps 4.1, 4.2 and 4.3: The issuing bank freezes the money if the transaction is approved. The approval or rejection is sent back to the acquirer, as well as the POS terminal.
+
+- Capture and Settlement Flow
+
+Steps 1 and 2: The merchant wants to collect the money at the end of the day, so they hit ”capture” on the POS terminal. The transactions are sent to the acquirer in batch. The acquirer sends the batch file with transactions to the card network.
+
+Step 3: The card network performs clearing for the transactions collected from different acquirers, and sends the clearing files to different issuing banks.
+
+Step 4: The issuing banks confirm the correctness of the clearing files, and transfer money to the relevant acquiring banks.
+
+Step 5: The acquiring bank then transfers money to the merchant’s bank.
+
+Step 4: The card network clears up the transactions from different acquiring banks. Clearing is a process in which mutual offset transactions are netted, so the number of total transactions is reduced.
+
+In the process, the card network takes on the burden of talking to each bank and receives service fees in return.
+
+### Payment Systems Around The World Series (Part 1): Unified Payments Interface (UPI) in India
+
+
+What’s UPI? UPI is an instant real-time payment system developed by the National Payments Corporation of India.
+
+It accounts for 60% of digital retail transactions in India today.
+
+UPI = payment markup language + standard for interoperable payments
+
+
+
+ 
+
+
+
+## DevOps
+
+### DevOps vs. SRE vs. Platform Engineering. What is the difference?
+
+The concepts of DevOps, SRE, and Platform Engineering have emerged at different times and have been developed by various individuals and organizations.
+
+
+ 
+
+
+DevOps as a concept was introduced in 2009 by Patrick Debois and Andrew Shafer at the Agile conference. They sought to bridge the gap between software development and operations by promoting a collaborative culture and shared responsibility for the entire software development lifecycle.
+
+SRE, or Site Reliability Engineering, was pioneered by Google in the early 2000s to address operational challenges in managing large-scale, complex systems. Google developed SRE practices and tools, such as the Borg cluster management system and the Monarch monitoring system, to improve the reliability and efficiency of their services.
+
+Platform Engineering is a more recent concept, building on the foundation of SRE engineering. The precise origins of Platform Engineering are less clear, but it is generally understood to be an extension of the DevOps and SRE practices, with a focus on delivering a comprehensive platform for product development that supports the entire business perspective.
+
+It's worth noting that while these concepts emerged at different times. They are all related to the broader trend of improving collaboration, automation, and efficiency in software development and operations.
+
+### What is k8s (Kubernetes)?
+
+K8s is a container orchestration system. It is used for container deployment and management. Its design is greatly impacted by Google’s internal system Borg.
+
+
+ 
+
+
+A k8s cluster consists of a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
+
+The worker node(s) host the Pods that are the components of the application workload. The control plane manages the worker nodes and the Pods in the cluster. In production environments, the control plane usually runs across multiple computers, and a cluster usually runs multiple nodes, providing fault tolerance and high availability.
+
+- Control Plane Components
+
+1. API Server
+
+ The API server talks to all the components in the k8s cluster. All the operations on pods are executed by talking to the API server.
+
+2. Scheduler
+
+ The scheduler watches pod workloads and assigns loads on newly created pods.
+
+3. Controller Manager
+
+ The controller manager runs the controllers, including Node Controller, Job Controller, EndpointSlice Controller, and ServiceAccount Controller.
+
+4. Etcd
+
+ etcd is a key-value store used as Kubernetes' backing store for all cluster data.
+
+- Nodes
+
+1. Pods
+
+ A pod is a group of containers and is the smallest unit that k8s administers. Pods have a single IP address applied to every container within the pod.
+
+2. Kubelet
+
+ An agent that runs on each node in the cluster. It ensures containers are running in a Pod.
+
+3. Kube Proxy
+
+ Kube-proxy is a network proxy that runs on each node in your cluster. It routes traffic coming into a node from the service. It forwards requests for work to the correct containers.
+
+### Docker vs. Kubernetes. Which one should we use?
+
+
+ 
+
+
+
+What is Docker ?
+
+Docker is an open-source platform that allows you to package, distribute, and run applications in isolated containers. It focuses on containerization, providing lightweight environments that encapsulate applications and their dependencies.
+
+What is Kubernetes ?
+
+Kubernetes, often referred to as K8s, is an open-source container orchestration platform. It provides a framework for automating the deployment, scaling, and management of containerized applications across a cluster of nodes.
+
+How are both different from each other ?
+
+Docker: Docker operates at the individual container level on a single operating system host.
+
+You must manually manage each host and setting up networks, security policies, and storage for multiple related containers can be complex.
+
+Kubernetes: Kubernetes operates at the cluster level. It manages multiple containerized applications across multiple hosts, providing automation for tasks like load balancing, scaling, and ensuring the desired state of applications.
+
+In short, Docker focuses on containerization and running containers on individual hosts, while Kubernetes specializes in managing and orchestrating containers at scale across a cluster of hosts.
+
+### How does Docker work?
+
+The diagram below shows the architecture of Docker and how it works when we run “docker build”, “docker pull”
+and “docker run”.
+
+
+ 
+
+
+There are 3 components in Docker architecture:
+
+- Docker client
+
+ The docker client talks to the Docker daemon.
+
+- Docker host
+
+ The Docker daemon listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes.
+
+- Docker registry
+
+ A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use.
+
+Let’s take the “docker run” command as an example.
+
+ 1. Docker pulls the image from the registry.
+ 1. Docker creates a new container.
+ 1. Docker allocates a read-write filesystem to the container.
+ 1. Docker creates a network interface to connect the container to the default network.
+ 1. Docker starts the container.
+
+## GIT
+
+### How Git Commands work
+
+To begin with, it's essential to identify where our code is stored. The common assumption is that there are only two locations - one on a remote server like Github and the other on our local machine. However, this isn't entirely accurate. Git maintains three local storages on our machine, which means that our code can be found in four places:
+
+
+ 
+
+
+
+- Working directory: where we edit files
+- Staging area: a temporary location where files are kept for the next commit
+- Local repository: contains the code that has been committed
+- Remote repository: the remote server that stores the code
+
+Most Git commands primarily move files between these four locations.
+
+### How does Git Work?
+
+The diagram below shows the Git workflow.
+
+
+ 
+
+
+
+Git is a distributed version control system.
+
+Every developer maintains a local copy of the main repository and edits and commits to the local copy.
+
+The commit is very fast because the operation doesn’t interact with the remote repository.
+
+If the remote repository crashes, the files can be recovered from the local repositories.
+
+### Git merge vs. Git rebase
+
+What are the differences?
+
+
+ 
+
+
+
+When we **merge changes** from one Git branch to another, we can use ‘git merge’ or ‘git rebase’. The diagram below shows how the two commands work.
+
+**Git merge**
+
+This creates a new commit G’ in the main branch. G’ ties the histories of both main and feature branches.
+
+Git merge is **non-destructive**. Neither the main nor the feature branch is changed.
+
+**Git rebase**
+
+Git rebase moves the feature branch histories to the head of the main branch. It creates new commits E’, F’, and G’ for each commit in the feature branch.
+
+The benefit of rebase is that it has a linear **commit history**.
+
+Rebase can be dangerous if “the golden rule of git rebase” is not followed.
+
+**The Golden Rule of Git Rebase**
+
+Never use it on public branches!
+
+## Cloud Services
+
+### A nice cheat sheet of different cloud services (2023 edition)
+
+
+ 
+
+
+
+### What is cloud native?
+
+Below is a diagram showing the evolution of architecture and processes since the 1980s.
+
+
+ 
+
+
+Organizations can build and run scalable applications on public, private, and hybrid clouds using cloud native technologies.
+
+This means the applications are designed to leverage cloud features, so they are resilient to load and easy to scale.
+
+Cloud native includes 4 aspects:
+
+1. Development process
+
+ This has progressed from waterfall to agile to DevOps.
+
+2. Application Architecture
+
+ The architecture has gone from monolithic to microservices. Each service is designed to be small, adaptive to the limited resources in cloud containers.
+
+3. Deployment & packaging
+
+ The applications used to be deployed on physical servers. Then around 2000, the applications that were not sensitive to latency were usually deployed on virtual servers. With cloud native applications, they are packaged into docker images and deployed in containers.
+
+4. Application infrastructure
+
+ The applications are massively deployed on cloud infrastructure instead of self-hosted servers.
+
+## Developer productivity tools
+
+### Visualize JSON files
+
+Nested JSON files are hard to read.
+
+**JsonCrack** generates graph diagrams from JSON files and makes them easy to read.
+
+Additionally, the generated diagrams can be downloaded as images.
+
+
+ 
+
+
+
+### Automatically turn code into architecture diagrams
+
+
+ 
+
+
+
+What does it do?
+
+- Draw the cloud system architecture in Python code.
+- Diagrams can also be rendered directly inside the Jupyter Notebooks.
+- No design tools are needed.
+- Supports the following providers: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud, etc.
+
+[Github repo](https://github.com/mingrammer/diagrams)
+
+## Linux
+
+### Linux file system explained
+
+
+ 
+
+
+The Linux file system used to resemble an unorganized town where individuals constructed their houses wherever they pleased. However, in 1994, the Filesystem Hierarchy Standard (FHS) was introduced to bring order to the Linux file system.
+
+By implementing a standard like the FHS, software can ensure a consistent layout across various Linux distributions. Nonetheless, not all Linux distributions strictly adhere to this standard. They often incorporate their own unique elements or cater to specific requirements.
+To become proficient in this standard, you can begin by exploring. Utilize commands such as "cd" for navigation and "ls" for listing directory contents. Imagine the file system as a tree, starting from the root (/). With time, it will become second nature to you, transforming you into a skilled Linux administrator.
+
+### 18 Most-used Linux Commands You Should Know
+
+Linux commands are instructions for interacting with the operating system. They help manage files, directories, system processes, and many other aspects of the system. You need to become familiar with these commands in order to navigate and maintain Linux-based systems efficiently and effectively.
+
+This diagram below shows popular Linux commands:
+
+
+ 
+
+
+
+- ls - List files and directories
+- cd - Change the current directory
+- mkdir - Create a new directory
+- rm - Remove files or directories
+- cp - Copy files or directories
+- mv - Move or rename files or directories
+- chmod - Change file or directory permissions
+- grep - Search for a pattern in files
+- find - Search for files and directories
+- tar - manipulate tarball archive files
+- vi - Edit files using text editors
+- cat - display the content of files
+- top - Display processes and resource usage
+- ps - Display processes information
+- kill - Terminate a process by sending a signal
+- du - Estimate file space usage
+- ifconfig - Configure network interfaces
+- ping - Test network connectivity between hosts
+
+## Security
+
+### How does HTTPS work?
+
+Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP.) HTTPS transmits encrypted data using Transport Layer Security (TLS.) If the data is hijacked online, all the hijacker gets is binary code.
+
+
+ 
+
+
+
+How is the data encrypted and decrypted?
+
+Step 1 - The client (browser) and the server establish a TCP connection.
+
+Step 2 - The client sends a “client hello” to the server. The message contains a set of necessary encryption algorithms (cipher suites) and the latest TLS version it can support. The server responds with a “server hello” so the browser knows whether it can support the algorithms and TLS version.
+
+The server then sends the SSL certificate to the client. The certificate contains the public key, host name, expiry dates, etc. The client validates the certificate.
+
+Step 3 - After validating the SSL certificate, the client generates a session key and encrypts it using the public key. The server receives the encrypted session key and decrypts it with the private key.
+
+Step 4 - Now that both the client and the server hold the same session key (symmetric encryption), the encrypted data is transmitted in a secure bi-directional channel.
+
+Why does HTTPS switch to symmetric encryption during data transmission? There are two main reasons:
+
+1. Security: The asymmetric encryption goes only one way. This means that if the server tries to send the encrypted data back to the client, anyone can decrypt the data using the public key.
+
+2. Server resources: The asymmetric encryption adds quite a lot of mathematical overhead. It is not suitable for data transmissions in long sessions.
+
+### Oauth 2.0 Explained With Simple Terms.
+
+OAuth 2.0 is a powerful and secure framework that allows different applications to securely interact with each other on behalf of users without sharing sensitive credentials.
+
+
+ 
+
+
+The entities involved in OAuth are the User, the Server, and the Identity Provider (IDP).
+
+What Can an OAuth Token Do?
+
+When you use OAuth, you get an OAuth token that represents your identity and permissions. This token can do a few important things:
+
+Single Sign-On (SSO): With an OAuth token, you can log into multiple services or apps using just one login, making life easier and safer.
+
+Authorization Across Systems: The OAuth token allows you to share your authorization or access rights across various systems, so you don't have to log in separately everywhere.
+
+Accessing User Profile: Apps with an OAuth token can access certain parts of your user profile that you allow, but they won't see everything.
+
+Remember, OAuth 2.0 is all about keeping you and your data safe while making your online experiences seamless and hassle-free across different applications and services.
+
+### Top 4 Forms of Authentication Mechanisms
+
+
+ 
+
+
+1. SSH Keys:
+
+ Cryptographic keys are used to access remote systems and servers securely
+
+1. OAuth Tokens:
+
+ Tokens that provide limited access to user data on third-party applications
+
+1. SSL Certificates:
+
+ Digital certificates ensure secure and encrypted communication between servers and clients
+
+1. Credentials:
+
+ User authentication information is used to verify and grant access to various systems and services
+
+### Session, cookie, JWT, token, SSO, and OAuth 2.0 - what are they?
+
+These terms are all related to user identity management. When you log into a website, you declare who you are (identification). Your identity is verified (authentication), and you are granted the necessary permissions (authorization). Many solutions have been proposed in the past, and the list keeps growing.
+
+
+ 
+
+
+From simple to complex, here is my understanding of user identity management:
+
+- WWW-Authenticate is the most basic method. You are asked for the username and password by the browser. As a result of the inability to control the login life cycle, it is seldom used today.
+
+- A finer control over the login life cycle is session-cookie. The server maintains session storage, and the browser keeps the ID of the session. A cookie usually only works with browsers and is not mobile app friendly.
+
+- To address the compatibility issue, the token can be used. The client sends the token to the server, and the server validates the token. The downside is that the token needs to be encrypted and decrypted, which may be time-consuming.
+
+- JWT is a standard way of representing tokens. This information can be verified and trusted because it is digitally signed. Since JWT contains the signature, there is no need to save session information on the server side.
+
+- By using SSO (single sign-on), you can sign on only once and log in to multiple websites. It uses CAS (central authentication service) to maintain cross-site information.
+
+- By using OAuth 2.0, you can authorize one website to access your information on another website.
+
+### How to store passwords safely in the database and how to validate a password?
+
+
+ 
+
+
+
+**Things NOT to do**
+
+- Storing passwords in plain text is not a good idea because anyone with internal access can see them.
+
+- Storing password hashes directly is not sufficient because it is pruned to precomputation attacks, such as rainbow tables.
+
+- To mitigate precomputation attacks, we salt the passwords.
+
+**What is salt?**
+
+According to OWASP guidelines, “a salt is a unique, randomly generated string that is added to each password as part of the hashing process”.
+
+**How to store a password and salt?**
+
+1. the hash result is unique to each password.
+1. The password can be stored in the database using the following format: hash(password + salt).
+
+**How to validate a password?**
+
+To validate a password, it can go through the following process:
+
+1. A client enters the password.
+1. The system fetches the corresponding salt from the database.
+1. The system appends the salt to the password and hashes it. Let’s call the hashed value H1.
+1. The system compares H1 and H2, where H2 is the hash stored in the database. If they are the same, the password is valid.
+
+### Explaining JSON Web Token (JWT) to a 10 year old Kid
+
+
+ 
+
+
+Imagine you have a special box called a JWT. Inside this box, there are three parts: a header, a payload, and a signature.
+
+The header is like the label on the outside of the box. It tells us what type of box it is and how it's secured. It's usually written in a format called JSON, which is just a way to organize information using curly braces { } and colons : .
+
+The payload is like the actual message or information you want to send. It could be your name, age, or any other data you want to share. It's also written in JSON format, so it's easy to understand and work with.
+Now, the signature is what makes the JWT secure. It's like a special seal that only the sender knows how to create. The signature is created using a secret code, kind of like a password. This signature ensures that nobody can tamper with the contents of the JWT without the sender knowing about it.
+
+When you want to send the JWT to a server, you put the header, payload, and signature inside the box. Then you send it over to the server. The server can easily read the header and payload to understand who you are and what you want to do.
+
+### How does Google Authenticator (or other types of 2-factor authenticators) work?
+
+Google Authenticator is commonly used for logging into our accounts when 2-factor authentication is enabled. How does it guarantee security?
+
+Google Authenticator is a software-based authenticator that implements a two-step verification service. The diagram below provides detail.
+
+
+ 
+
+
+
+There are two stages involved:
+
+- Stage 1 - The user enables Google two-step verification.
+- Stage 2 - The user uses the authenticator for logging in, etc.
+
+Let’s look at these stages.
+
+**Stage 1**
+
+Steps 1 and 2: Bob opens the web page to enable two-step verification. The front end requests a secret key. The authentication service generates the secret key for Bob and stores it in the database.
+
+Step 3: The authentication service returns a URI to the front end. The URI is composed of a key issuer, username, and secret key. The URI is displayed in the form of a QR code on the web page.
+
+Step 4: Bob then uses Google Authenticator to scan the generated QR code. The secret key is stored in the authenticator.
+
+**Stage 2**
+Steps 1 and 2: Bob wants to log into a website with Google two-step verification. For this, he needs the password. Every 30 seconds, Google Authenticator generates a 6-digit password using TOTP (Time-based One Time Password) algorithm. Bob uses the password to enter the website.
+
+Steps 3 and 4: The frontend sends the password Bob enters to the backend for authentication. The authentication service reads the secret key from the database and generates a 6-digit password using the same TOTP algorithm as the client.
+
+Step 5: The authentication service compares the two passwords generated by the client and the server, and returns the comparison result to the frontend. Bob can proceed with the login process only if the two passwords match.
+
+Is this authentication mechanism safe?
+
+- Can the secret key be obtained by others?
+
+ We need to make sure the secret key is transmitted using HTTPS. The authenticator client and the database store the secret key, and we need to make sure the secret keys are encrypted.
+
+- Can the 6-digit password be guessed by hackers?
+
+ No. The password has 6 digits, so the generated password has 1 million potential combinations. Plus, the password changes every 30 seconds. If hackers want to guess the password in 30 seconds, they need to enter 30,000 combinations per second.
+
+
+## Real World Case Studies
+
+### Netflix's Tech Stack
+
+This post is based on research from many Netflix engineering blogs and open-source projects. If you come across any inaccuracies, please feel free to inform us.
+
+
+ 
+
+
+**Mobile and web**: Netflix has adopted Swift and Kotlin to build native mobile apps. For its web application, it uses React.
+
+**Frontend/server communication**: Netflix uses GraphQL.
+
+**Backend services**: Netflix relies on ZUUL, Eureka, the Spring Boot framework, and other technologies.
+
+**Databases**: Netflix utilizes EV cache, Cassandra, CockroachDB, and other databases.
+
+**Messaging/streaming**: Netflix employs Apache Kafka and Fink for messaging and streaming purposes.
+
+**Video storage**: Netflix uses S3 and Open Connect for video storage.
+
+**Data processing**: Netflix utilizes Flink and Spark for data processing, which is then visualized using Tableau. Redshift is used for processing structured data warehouse information.
+
+**CI/CD**: Netflix employs various tools such as JIRA, Confluence, PagerDuty, Jenkins, Gradle, Chaos Monkey, Spinnaker, Atlas, and more for CI/CD processes.
+
+### Twitter Architecture 2022
+
+Yes, this is the real Twitter architecture. It is posted by Elon Musk and redrawn by us for better readability.
+
+
+ 
+
+
+
+### Evolution of Airbnb’s microservice architecture over the past 15 years
+
+Airbnb’s microservice architecture went through 3 main stages.
+
+
+ 
+
+
+
+Monolith (2008 - 2017)
+
+Airbnb began as a simple marketplace for hosts and guests. This is built in a Ruby on Rails application - the monolith.
+
+What’s the challenge?
+
+- Confusing team ownership + unowned code
+- Slow deployment
+
+Microservices (2017 - 2020)
+
+Microservice aims to solve those challenges. In the microservice architecture, key services include:
+
+- Data fetching service
+- Business logic data service
+- Write workflow service
+- UI aggregation service
+- Each service had one owning team
+
+What’s the challenge?
+
+Hundreds of services and dependencies were difficult for humans to manage.
+
+Micro + macroservices (2020 - present)
+
+This is what Airbnb is working on now. The micro and macroservice hybrid model focuses on the unification of APIs.
+
+### Monorepo vs. Microrepo.
+
+Which is the best? Why do different companies choose different options?
+
+
+ 
+
+
+
+Monorepo isn't new; Linux and Windows were both created using Monorepo. To improve scalability and build speed, Google developed its internal dedicated toolchain to scale it faster and strict coding quality standards to keep it consistent.
+
+Amazon and Netflix are major ambassadors of the Microservice philosophy. This approach naturally separates the service code into separate repositories. It scales faster but can lead to governance pain points later on.
+
+Within Monorepo, each service is a folder, and every folder has a BUILD config and OWNERS permission control. Every service member is responsible for their own folder.
+
+On the other hand, in Microrepo, each service is responsible for its repository, with the build config and permissions typically set for the entire repository.
+
+In Monorepo, dependencies are shared across the entire codebase regardless of your business, so when there's a version upgrade, every codebase upgrades their version.
+
+In Microrepo, dependencies are controlled within each repository. Businesses choose when to upgrade their versions based on their own schedules.
+
+Monorepo has a standard for check-ins. Google's code review process is famously known for setting a high bar, ensuring a coherent quality standard for Monorepo, regardless of the business.
+
+Microrepo can either set its own standard or adopt a shared standard by incorporating the best practices. It can scale faster for business, but the code quality might be a bit different.
+Google engineers built Bazel, and Meta built Buck. There are other open-source tools available, including Nix, Lerna, and others.
+
+Over the years, Microrepo has had more supported tools, including Maven and Gradle for Java, NPM for NodeJS, and CMake for C/C++, among others.
+
+### How will you design the Stack Overflow website?
+
+If your answer is on-premise servers and monolith (on the bottom of the following image), you would likely fail the interview, but that's how it is built in reality!
+
+
+ 
+
+
+
+**What people think it should look like**
+
+The interviewer is probably expecting something like the top portion of the picture.
+
+- Microservice is used to decompose the system into small components.
+- Each service has its own database. Use cache heavily.
+- The service is sharded.
+- The services talk to each other asynchronously through message queues.
+- The service is implemented using Event Sourcing with CQRS.
+- Showing off knowledge in distributed systems such as eventual consistency, CAP theorem, etc.
+
+**What it actually is**
+
+Stack Overflow serves all the traffic with only 9 on-premise web servers, and it’s on monolith! It has its own servers and does not run on the cloud.
+
+This is contrary to all our popular beliefs these days.
+
+### Why did Amazon Prime Video monitoring move from serverless to monolithic? How can it save 90% cost?
+
+The diagram below shows the architecture comparison before and after the migration.
+
+
+ 
+
+
+
+What is Amazon Prime Video Monitoring Service?
+
+Prime Video service needs to monitor the quality of thousands of live streams. The monitoring tool automatically analyzes the streams in real time and identifies quality issues like block corruption, video freeze, and sync problems. This is an important process for customer satisfaction.
+
+There are 3 steps: media converter, defect detector, and real-time notification.
+
+- What is the problem with the old architecture?
+
+ The old architecture was based on Amazon Lambda, which was good for building services quickly. However, it was not cost-effective when running the architecture at a high scale. The two most expensive operations are:
+
+1. The orchestration workflow - AWS step functions charge users by state transitions and the orchestration performs multiple state transitions every second.
+
+2. Data passing between distributed components - the intermediate data is stored in Amazon S3 so that the next stage can download. The download can be costly when the volume is high.
+
+- Monolithic architecture saves 90% cost
+
+ A monolithic architecture is designed to address the cost issues. There are still 3 components, but the media converter and defect detector are deployed in the same process, saving the cost of passing data over the network. Surprisingly, this approach to deployment architecture change led to 90% cost savings!
+
+This is an interesting and unique case study because microservices have become a go-to and fashionable choice in the tech industry. It's good to see that we are having more discussions about evolving the architecture and having more honest discussions about its pros and cons. Decomposing components into distributed microservices comes with a cost.
+
+- What did Amazon leaders say about this?
+
+ Amazon CTO Werner Vogels: “Building **evolvable software systems** is a strategy, not a religion. And revisiting your architecture with an open mind is a must.”
+
+Ex Amazon VP Sustainability Adrian Cockcroft: “The Prime Video team had followed a path I call **Serverless First**…I don’t advocate **Serverless Only**”.
+
+### How does Disney Hotstar capture 5 Billion Emojis during a tournament?
+
+
+ 
+
+
+
+1. Clients send emojis through standard HTTP requests. You can think of Golang Service as a typical Web Server. Golang is chosen because it supports concurrency well. Threads in Golang are lightweight.
+
+2. Since the write volume is very high, Kafka (message queue) is used as a buffer.
+
+3. Emoji data are aggregated by a streaming processing service called Spark. It aggregates data every 2 seconds, which is configurable. There is a trade-off to be made based on the interval. A shorter interval means emojis are delivered to other clients faster but it also means more computing resources are needed.
+
+4. Aggregated data is written to another Kafka.
+
+5. The PubSub consumers pull aggregated emoji data from Kafka.
+
+6. Emojis are delivered to other clients in real-time through the PubSub infrastructure. The PubSub infrastructure is interesting. Hotstar considered the following protocols: Socketio, NATS, MQTT, and gRPC, and settled with MQTT.
+
+A similar design is adopted by LinkedIn which streams a million likes/sec.
+
+### How Discord Stores Trillions Of Messages
+
+The diagram below shows the evolution of message storage at Discord:
+
+
+ 
+
+
+
+MongoDB ➡️ Cassandra ➡️ ScyllaDB
+
+In 2015, the first version of Discord was built on top of a single MongoDB replica. Around Nov 2015, MongoDB stored 100 million messages and the RAM couldn’t hold the data and index any longer. The latency became unpredictable. Message storage needs to be moved to another database. Cassandra was chosen.
+
+In 2017, Discord had 12 Cassandra nodes and stored billions of messages.
+
+At the beginning of 2022, it had 177 nodes with trillions of messages. At this point, latency was unpredictable, and maintenance operations became too expensive to run.
+
+There are several reasons for the issue:
+
+- Cassandra uses the LSM tree for the internal data structure. The reads are more expensive than the writes. There can be many concurrent reads on a server with hundreds of users, resulting in hotspots.
+- Maintaining clusters, such as compacting SSTables, impacts performance.
+- Garbage collection pauses would cause significant latency spikes
+
+ScyllaDB is Cassandra compatible database written in C++. Discord redesigned its architecture to have a monolithic API, a data service written in Rust, and ScyllaDB-based storage.
+
+The p99 read latency in ScyllaDB is 15ms compared to 40-125ms in Cassandra. The p99 write latency is 5ms compared to 5-70ms in Cassandra.
+
+### How do video live streamings work on YouTube, TikTok live, or Twitch?
+
+Live streaming differs from regular streaming because the video content is sent via the internet in real-time, usually with a latency of just a few seconds.
+
+The diagram below explains what happens behind the scenes to make this possible.
+
+
+ 
+
+
+
+Step 1: The raw video data is captured by a microphone and camera. The data is sent to the server side.
+
+Step 2: The video data is compressed and encoded. For example, the compressing algorithm separates the background and other video elements. After compression, the video is encoded to standards such as H.264. The size of the video data is much smaller after this step.
+
+Step 3: The encoded data is divided into smaller segments, usually seconds in length, so it takes much less time to download or stream.
+
+Step 4: The segmented data is sent to the streaming server. The streaming server needs to support different devices and network conditions. This is called ‘Adaptive Bitrate Streaming.’ This means we need to produce multiple files at different bitrates in steps 2 and 3.
+
+Step 5: The live streaming data is pushed to edge servers supported by CDN (Content Delivery Network.) Millions of viewers can watch the video from an edge server nearby. CDN significantly lowers data transmission latency.
+
+Step 6: The viewers’ devices decode and decompress the video data and play the video in a video player.
+
+Steps 7 and 8: If the video needs to be stored for replay, the encoded data is sent to a storage server, and viewers can request a replay from it later.
+
+Standard protocols for live streaming include:
+
+- RTMP (Real-Time Messaging Protocol): This was originally developed by Macromedia to transmit data between a Flash player and a server. Now it is used for streaming video data over the internet. Note that video conferencing applications like Skype use RTC (Real-Time Communication) protocol for lower latency.
+- HLS (HTTP Live Streaming): It requires the H.264 or H.265 encoding. Apple devices accept only HLS format.
+- DASH (Dynamic Adaptive Streaming over HTTP): DASH does not support Apple devices.
+- Both HLS and DASH support adaptive bitrate streaming.
+
+## License
+
+This work is licensed under CC BY-NC-ND 4.0
From e545f48aef3f7d47bb5d992c862bd324d2018ad7 Mon Sep 17 00:00:00 2001
From: realtemirov
Date: Wed, 22 Nov 2023 22:29:27 +0500
Subject: [PATCH 4/8] ci/cd
---
translations/README-uz.md | 98 +++++++++++++++++++--------------------
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/translations/README-uz.md b/translations/README-uz.md
index bc5d3f4..e4c4480 100644
--- a/translations/README-uz.md
+++ b/translations/README-uz.md
@@ -40,20 +40,20 @@ Tizim dizayni bo'yicha intervyuga tayyorlanyapsizmi yoki tizimlar qanday ishlash
- [Umumiy yuklarni muvozanatlash algoritmlari qanday?](#umumiy-yuklarni-muvozanatlash-algoritmlari-qanday)
- [URL, URI, URN - Farqlarni bilasizmi?](#url-uri-urn---farqlarni-bilasizmi)
- [CI/CD](#cicd)
- - [CI/CD quvur liniyasi oddiy so'zlar bilan tushuntirilgan](#cicd-pipeline-explained-in-simple-terms)
+ - [CI/CD quvur liniyasi oddiy so'zlar bilan tushuntirilgan](#cicd-quvur-liniyasi-oddiy-sozlar-bilan-tushuntirilgan)
- [Netflix Tech Stack (CI/CD Pipeline)](#netflix-tech-stack-cicd-pipeline)
-- [Arxitektura naqshlari](#architecture-patterns)
- - [MVC, MVP, MVVM, MVVM-C va VIPER](#mvc-mvp-mvvm-mvvm-c-and-viper)
- - [Har bir dasturchi bilishi kerak bo'lgan 18 ta asosiy dizayn naqshlari](#18-key-design-patterns-every-developer-should-know)
-- [Ma'lumotlar bazasi](#database)
- - [Bulutli xizmatlardagi turli xil ma'lumotlar bazalarining chiroyli cheat varag'i ](#a-nice-cheat-sheet-of-different-databases-in-cloud-services)
- - [Ma'lumotlar bazalaringizni quvvatlantiradigan 8 ta ma'lumotlar tuzilmasi](#8-data-structures-that-power-your-databases)
- - [Ma'lumotlar bazasida SQL operatori qanday bajariladi?](#how-is-an-sql-statement-executed-in-the-database)
- - [CAP teoremasi](#cap-theorem)
- - [Xotira va saqlash turlari](#types-of-memory-and-storage)
- - [SQL so'rovini vizualizatsiya qilish](#visualizing-a-sql-query)
- - [SQL tili](#sql-language)
-- [Kesh](#cache)
+- [Arxitektura naqshlari](#arxitektura-naqshlari)
+ - [MVC, MVP, MVVM, MVVM-C va VIPER](#mvc-mvp-mvvm-mvvm-c-va-viper)
+ - [Har bir dasturchi bilishi kerak bo'lgan 18 ta asosiy dizayn naqshlari](#har-bir-dasturchi-bilishi-kerak-bolgan-18-ta-asosiy-dizayn-naqshlari)
+- [Ma'lumotlar bazasi](#malumotlar-bazasi)
+ - [Bulutli xizmatlardagi turli xil ma'lumotlar bazalarining chiroyli cheat varag'i](#bulutli-xizmatlardagi-turli-xil-malumotlar-bazalarining-chiroyli-cheat-varagi)
+ - [Ma'lumotlar bazalaringizni quvvatlantiradigan 8 ta ma'lumotlar tuzilmasi](#malumotlar-bazalaringizni-quvvatlantiradigan-8-ta-malumotlar-tuzilmasi)
+ - [Ma'lumotlar bazasida SQL operatori qanday bajariladi?](#malumotlar-bazasida-sql-operatori-qanday-bajariladi)
+ - [CAP teoremasi](#cap-teoremasi)
+ - [Xotira va saqlash turlari](#xotira-va-saqlash-turlari)
+ - [SQL so'rovini vizualizatsiya qilish](#sql-sorovini-vizualizatsiya-qilish)
+ - [SQL tili](#sql-tili)
+- [Kesh](#kesh)
- [Ma'lumotlar hamma joyda keshlangan](#data-is-cached-everywhere)
- [Nima uchun Redis juda tez?](#why-is-redis-so-fast)
- [Redis-dan qanday foydalanish mumkin?](#how-can-redis-be-used)
@@ -491,34 +491,34 @@ Agar siz ushbu mavzu bo'yicha batafsil ma'lumot olishni istasangiz, men [W3C'nin
## CI/CD
-### CI/CD Pipeline Explained in Simple Terms
+### CI/CD quvur liniyasi oddiy so'zlar bilan tushuntirilgan
-Section 1 - SDLC with CI/CD
+1-bo'lim - CI/CD bilan SDLC
-The software development life cycle (SDLC) consists of several key stages: development, testing, deployment, and maintenance. CI/CD automates and integrates these stages to enable faster and more reliable releases.
+Dasturiy ta'minotni ishlab chiqish hayotiy tsikli (SDLC) bir necha asosiy bosqichlardan iborat: ishlab chiqish, sinovdan o'tkazish, joylashtirish va texnik xizmat ko'rsatish. CI/CD tezroq va ishonchli relizlarni yoqish uchun ushbu bosqichlarni avtomatlashtiradi va birlashtiradi.
-When code is pushed to a git repository, it triggers an automated build and test process. End-to-end (e2e) test cases are run to validate the code. If tests pass, the code can be automatically deployed to staging/production. If issues are found, the code is sent back to development for bug fixing. This automation provides fast feedback to developers and reduces the risk of bugs in production.
+Kod git omboriga yuborilsa, u avtomatlashtirilgan qurish va sinov jarayonini ishga tushiradi. Kodni tekshirish uchun end-to-end (e2e) test holatlari ishga tushiriladi. Agar testlar muvaffaqiyatli o'tsa, kod avtomatik ravishda sahnalashtirish/ishlab chiqarishga o'rnatilishi mumkin. Muammolar aniqlansa, kod xatolarni tuzatish uchun ishlab chiqishga qaytariladi. Ushbu avtomatlashtirish ishlab chiquvchilarga tezkor javob beradi va ishlab chiqarishdagi xatolar xavfini kamaytiradi.
-Section 2 - Difference between CI and CD
+2-bo'lim - CI va CD o'rtasidagi farq
-Continuous Integration (CI) automates the build, test, and merge process. It runs tests whenever code is committed to detect integration issues early. This encourages frequent code commits and rapid feedback.
+Uzluksiz integratsiya (CI) qurish, sinovdan o'tkazish va birlashtirish jarayonini avtomatlashtiradi. U integratsiya muammolarini erta aniqlash uchun kod so'ralganda testlarni o'tkazadi. Bu tez-tez kod topshirishni va tezkor fikr-mulohazalarni rag'batlantiradi.
-Continuous Delivery (CD) automates release processes like infrastructure changes and deployment. It ensures software can be released reliably at any time through automated workflows. CD may also automate the manual testing and approval steps required before production deployment.
+Uzluksiz yetkazib berish (CD) infratuzilmani o'zgartirish va joylashtirish kabi reliz jarayonlarini avtomatlashtiradi. Bu dasturiy ta'minotni avtomatlashtirilgan ish oqimlari orqali istalgan vaqtda ishonchli tarzda chiqarishni ta'minlaydi. CD, shuningdek, ishlab chiqarishni joylashtirishdan oldin talab qilinadigan qo'lda sinov va tasdiqlash bosqichlarini avtomatlashtirishi mumkin.
-Section 3 - CI/CD Pipeline
+3-bo'lim - CI/CD quvur liniyasi
-A typical CI/CD pipeline has several connected stages:
-- The developer commits code changes to the source control
-- CI server detects changes and triggers the build
-- Code is compiled, and tested (unit, integration tests)
-- Test results reported to the developer
-- On success, artifacts are deployed to staging environments
-- Further testing may be done on staging before release
-- CD system deploys approved changes to production
+Oddiy CI/CD quvur liniyasi bir nechta bog'langan bosqichlarga ega:
+- Ishlab chiquvchi manba boshqaruviga kod o'zgarishlarini kiritadi
+- CI server o'zgarishlarni aniqlaydi va qurilishni ishga tushiradi
+- Kod tuzilgan va sinovdan o'tgan (birlik, integratsiya testlari)
+- Sinov natijalari ishlab chiquvchiga xabar qilinadi
+- Muvaffaqiyatga erishgandan so'ng, artefaktlar sahnalashtirish muhitiga joylashtiriladi
+- Chiqarishdan oldin sahnalashtirishda qo'shimcha sinovlar o'tkazilishi mumkin
+- CD tizimi ishlab chiqarishga tasdiqlangan o'zgarishlarni kiritadi
### Netflix Tech Stack (CI/CD Pipeline)
@@ -526,25 +526,25 @@ A typical CI/CD pipeline has several connected stages:
-Planning: Netflix Engineering uses JIRA for planning and Confluence for documentation.
+Rejalashtirish: Netflix Engineering rejalashtirish uchun JIRA va hujjatlar uchun Confluence-dan foydalanadi.
-Coding: Java is the primary programming language for the backend service, while other languages are used for different use cases.
+Kodlash: Java backend xizmati uchun asosiy dasturlash tilidir, boshqa tillar esa turli xil foydalanish holatlari uchun ishlatiladi.
-Build: Gradle is mainly used for building, and Gradle plugins are built to support various use cases.
+Build: Gradle asosan qurilish uchun ishlatiladi va Gradle plaginlari turli xil foydalanish holatlarini qo'llab-quvvatlash uchun qurilgan.
-Packaging: Package and dependencies are packed into an Amazon Machine Image (AMI) for release.
+Qadoqlash: Paket va bog'liqliklar chiqarish uchun Amazon Machine Image (AMI) ichiga qadoqlangan.
-Testing: Testing emphasizes the production culture's focus on building chaos tools.
+Sinov: Sinov ishlab chiqarish madaniyatining betartiblik vositalarini yaratishga qaratilganligini ta'kidlaydi.
-Deployment: Netflix uses its self-built Spinnaker for canary rollout deployment.
+Joylashtirish: Netflix kanareykalarni tarqatish uchun o'z-o'zidan ishlab chiqarilgan Spinnaker-dan foydalanadi.
-Monitoring: The monitoring metrics are centralized in Atlas, and Kayenta is used to detect anomalies.
+Monitoring: Monitoring ko'rsatkichlari Atlasda markazlashtirilgan va Kayenta anomaliyalarni aniqlash uchun ishlatiladi.
-Incident report: Incidents are dispatched according to priority, and PagerDuty is used for incident handling.
+Voqea haqida hisobot: Hodisalar ustuvorlikka ko'ra jo'natiladi va PagerDuty hodisani hal qilish uchun ishlatiladi.
-## Architecture patterns
+## Arxitektura naqshlari
-### MVC, MVP, MVVM, MVVM-C, and VIPER
+### MVC, MVP, MVVM, MVVM-C va VIPER
These architecture patterns are among the most commonly used in app development, whether on iOS or Android platforms. Developers have introduced them to overcome the limitations of earlier patterns. So, how do they differ?
@@ -556,7 +556,7 @@ These architecture patterns are among the most commonly used in app development,
- Most patterns include a "model" (M) to manage business data
- "Controller," "presenter," and "view-model" are translators that mediate between the view and the model ("entity" in the VIPER pattern)
-### 18 Key Design Patterns Every Developer Should Know
+### Har bir dasturchi bilishi kerak bo'lgan 18 ta asosiy dizayn naqshlari
Patterns are reusable solutions to common design problems, resulting in a smoother, more efficient development process. They serve as blueprints for building better software structures. These are some of the most popular patterns:
@@ -583,9 +583,9 @@ Patterns are reusable solutions to common design problems, resulting in a smooth
- Observer: News Broadcaster - Notifies classes about changes in other objects.
- Visitor: Skillful Guest - Adds new operations to a class without altering it.
-## Database
+## Ma'lumotlar bazasi
-### A nice cheat sheet of different databases in cloud services
+### Bulutli xizmatlardagi turli xil ma'lumotlar bazalarining chiroyli cheat varag'i
@@ -597,7 +597,7 @@ We hope this cheat sheet provides high-level direction to pinpoint the right ser
Note: Google has limited documentation for their database use cases. Even though we did our best to look at what was available and arrived at the best option, some of the entries may need to be more accurate.
-### 8 Data Structures That Power Your Databases
+### Ma'lumotlar bazalaringizni quvvatlantiradigan 8 ta ma'lumotlar tuzilmasi
The answer will vary depending on your use case. Data can be indexed in memory or on disk. Similarly, data formats vary, such as numbers, strings, geographic coordinates, etc. The system might be write-heavy or read-heavy. All of these factors affect your choice of database index format.
@@ -616,7 +616,7 @@ The following are some of the most popular data structures used for indexing dat
- Suffix tree: for string pattern search
- R-tree: multi-dimension search, such as finding the nearest neighbor
-### How is an SQL statement executed in the database?
+### Ma'lumotlar bazasida SQL operatori qanday bajariladi?
The diagram below shows the process. Note that the architectures for different databases are different, the diagram demonstrates some common designs.
@@ -641,7 +641,7 @@ Step 7 - If the statement is an UPDATE or INSERT, it is passed to the transactio
Step 8 - During a transaction, the data is in lock mode. This is guaranteed by the lock manager. It also ensures the transaction’s ACID properties.
-### CAP theorem
+### CAP teoremasi
The CAP theorem is one of the most famous terms in computer science, but I bet different developers have different understandings. Let’s examine what it is and why it can be confusing.
@@ -669,14 +669,14 @@ The “2 of 3” formulation can be useful, **but this simplification could be m
I think it is still useful as it opens our minds to a set of tradeoff discussions, but it is only part of the story. We need to dig deeper when picking the right database.
-### Types of Memory and Storage
+### Xotira va saqlash turlari
-### Visualizing a SQL query
+### SQL so'rovini vizualizatsiya qilish
@@ -696,7 +696,7 @@ The execution of SQL is highly complex and involves many considerations, such as
- Concurrency control
- Transaction management
-### SQL language
+### SQL tili
In 1986, SQL (Structured Query Language) became a standard. Over the next 40 years, it became the dominant language for relational database management systems. Reading the latest standard (ANSI SQL 2016) can be time-consuming. How can I learn it?
@@ -714,7 +714,7 @@ There are 5 components of the SQL language:
For a backend engineer, you may need to know most of it. As a data analyst, you may need to have a good understanding of DQL. Select the topics that are most relevant to you.
-## Cache
+## Kesh
### Data is cached everywhere
From 06c364c30c5e8767d84161b2ed8097d68bd2a4c1 Mon Sep 17 00:00:00 2001
From: realtemirov
Date: Fri, 24 Nov 2023 00:52:08 +0500
Subject: [PATCH 5/8] Why is Kafka fast
---
translations/README-uz.md | 527 +++++++++++++++++++-------------------
1 file changed, 263 insertions(+), 264 deletions(-)
diff --git a/translations/README-uz.md b/translations/README-uz.md
index e4c4480..44857ce 100644
--- a/translations/README-uz.md
+++ b/translations/README-uz.md
@@ -54,56 +54,56 @@ Tizim dizayni bo'yicha intervyuga tayyorlanyapsizmi yoki tizimlar qanday ishlash
- [SQL so'rovini vizualizatsiya qilish](#sql-sorovini-vizualizatsiya-qilish)
- [SQL tili](#sql-tili)
- [Kesh](#kesh)
- - [Ma'lumotlar hamma joyda keshlangan](#data-is-cached-everywhere)
- - [Nima uchun Redis juda tez?](#why-is-redis-so-fast)
- - [Redis-dan qanday foydalanish mumkin?](#how-can-redis-be-used)
- - [Eng yaxshi keshlash strategiyalari](#top-caching-strategies)
-- [Mikroservis arxitekturasi](#microservice-architecture)
- - [Oddiy mikroservis arxitekturasi nimaga o'xshaydi?](#what-does-a-typical-microservice-architecture-look-like)
- - [Mikroservisning eng yaxshi amaliyotlari](#microservice-best-practices)
- - [Mikroservislar uchun qanday texnologik stek ishlatiladi?](#what-tech-stack-is-commonly-used-for-microservices)
- - [Nega Kafka tez](#why-is-kafka-fast)
-- [To'lov tizimlari](#payment-systems)
- - [To'lov tizimini qanday o'rganish mumkin?](#how-to-learn-payment-systems)
- - [Nima uchun kredit karta "banklardagi eng daromadli mahsulot" deb ataladi? VISA/Mastercard qanday qilib pul ishlaydi?](#why-is-the-credit-card-called-the-most-profitable-product-in-banks-how-does-visamastercard-make-money)
- - [Savdogarlar do'konida kredit kartani o'tkazganimizda VISA qanday ishlaydi?](#how-does-visa-work-when-we-swipe-a-credit-card-at-a-merchants-shop)
- - [Dunyo bo'ylab to'lov tizimlari seriyasi (1-qism): Hindistonda yagona to'lov interfeysi (UPI)](#payment-systems-around-the-world-series-part-1-unified-payments-interface-upi-in-india)
+ - [Ma'lumotlar hamma joyda keshlangan](#malumotlar-hamma-joyda-keshlangan)
+ - [Nima uchun Redis juda tez?](#nima-uchun-redis-juda-tez)
+ - [Redisdan qanday foydalanish mumkin?](#redisdan-qanday-foydalanish-mumkin)
+ - [Eng yaxshi keshlash strategiyalari](#eng-yaxshi-keshlash-strategiyalari )
+- [Mikroservis arxitekturasi](#mikroservis-arxitekturasi)
+ - [Oddiy mikroservis arxitekturasi nimaga o'xshaydi?](#oddiy-mikroservis-arxitekturasi-nimaga-oxshaydi)
+ - [Mikroservisning eng yaxshi amaliyotlari](#mikroservisning-eng-yaxshi-amaliyotlari)
+ - [Mikroservislar uchun qanday texnologik stek ishlatiladi?](#mikroservislar-uchun-qanday-texnologik-stek-ishlatiladi)
+ - [Nega Kafka tez](#nega-kafka-tez)
+- [To'lov tizimlari](#tolov-tizimlari)
+ - [To'lov tizimini qanday o'rganish mumkin?](#tolov-tizimini-qanday-organish-mumkin)
+ - [Nima uchun kredit karta "banklardagi eng daromadli mahsulot" deb ataladi? VISA/Mastercard qanday qilib pul ishlaydi?](#nima-uchun-kredit-karta-banklardagi-eng-daromadli-mahsulot-deb-ataladi-visamastercard-qanday-qilib-pul-ishlaydi)
+ - [Savdogarlar do'konida kredit kartani o'tkazganimizda VISA qanday ishlaydi?](#savdogarlar-dokonida-kredit-kartani-otkazganimizda-visa-qanday-ishlaydi)
+ - [Dunyo bo'ylab to'lov tizimlari seriyasi (1-qism): Hindistonda yagona to'lov interfeysi (UPI)](#dunyo-boylab-tolov-tizimlari-seriyasi-1-qism-hindistonda-yagona-tolov-interfeysi-upi)
- [DevOps](#devops)
- - [DevOps va SRE va platforma muhandisligi. Farqi nimada?](#devops-vs-sre-vs-platform-engineering-what-is-the-difference)
- - [K8s (Kubernetes) nima?](#what-is-k8s-kubernetes)
- - [Docker va Kubernetes. Qaysi birini ishlatishimiz kerak?](#docker-vs-kubernetes-which-one-should-we-use)
- - [Docker qanday ishlaydi?](#how-does-docker-work)
+ - [DevOps va SRE va platforma muhandisligi. Farqi nimada?](#devops-va-sre-va-platforma-muhandisligi-farqi-nimada)
+ - [K8s (Kubernetes) nima?](#k8s-kubernetes-nima)
+ - [Docker va Kubernetes. Qaysi birini ishlatishimiz kerak?](#docker-va-kubernetes-qaysi-birini-ishlatishimiz-kerak)
+ - [Docker qanday ishlaydi?](#docker-qanday-ishlaydi)
- [GIT](#git)
- - [Git buyruqlari qanday ishlaydi](#how-git-commands-work)
- - [Git qanday ishlaydi?](#how-does-git-work)
- - [Git merge va Git rebase](#git-merge-vs-git-rebase)
-- [Bulutli xizmatlar](#cloud-services)
- - [Turli xil bulut xizmatlarining chiroyli cheat varag'i (2023 yil nashri)](#a-nice-cheat-sheet-of-different-cloud-services-2023-edition)
- - [Mahalliy bulut nima?](#what-is-cloud-native)
-- [Ishlab chiquvchi mahsuldorlik vositalari](#developer-productivity-tools)
- - [JSON fayllarini vizualizatsiya qilish](#visualize-json-files)
- - [Kodni avtomatik ravishda arxitektura diagrammalariga aylantiring](#automatically-turn-code-into-architecture-diagrams)
+ - [Git buyruqlari qanday ishlaydi](#git-buyruqlari-qanday-ishlaydi)
+ - [Git qanday ishlaydi?](#git-qanday-ishlaydi)
+ - [Git merge va Git rebase](#git-merge-va-git-rebase)
+- [Bulutli xizmatlar](#bulutli-xizmatlar)
+ - [Turli xil bulut xizmatlarining chiroyli cheat varag'i (2023 yil nashri)](#turli-xil-bulut-xizmatlarining-chiroyli-cheat-varagi-2023-yil-nashri)
+ - [Mahalliy bulut nima?](#mahalliy-bulut-nima)
+- [Ishlab chiquvchi mahsuldorlik vositalari](#ishlab-chiquvchi-mahsuldorlik-vositalari)
+ - [JSON fayllarini vizualizatsiya qilish](#json-fayllarini-vizualizatsiya-qilish)
+ - [Kodni avtomatik ravishda arxitektura diagrammalariga aylantiring](#kodni-avtomatik-ravishda-arxitektura-diagrammalariga-aylantiring)
- [Linux](#linux)
- - [Linux fayl tizimi tushuntirildi](#linux-file-system-explained)
- - [Siz bilishingiz kerak bo'lgan 18 ta eng ko'p ishlatiladigan Linux buyruqlari](#18-most-used-linux-commands-you-should-know)
-- [Xavfsizlik](#security)
- - [HTTPS qanday ishlaydi?](#how-does-https-work)
- - [Oauth 2.0 oddiy shartlar bilan tushuntirilgan.](#oauth-20-explained-with-simple-terms)
- - [Autentifikatsiya mexanizmlarining 4 ta eng yaxshi shakllari](#top-4-forms-of-authentication-mechanisms)
- - [Sessiya, cookie, JWT, token, SSO va OAuth 2.0 - ular nima?](#session-cookie-jwt-token-sso-and-oauth-20---what-are-they)
- - [Ma'lumotlar bazasida parollarni qanday xavfsiz saqlash va parolni qanday tekshirish mumkin?](#how-to-store-passwords-safely-in-the-database-and-how-to-validate-a-password)
- - [10 yoshli bolaga JSON Web Token (JWT) haqida tushuntirish](#explaining-json-web-token-jwt-to-a-10-year-old-kid)
- - [Google Authenticator (yoki 2 faktorli autentifikatsiyaning boshqa turlari) qanday ishlaydi?](#how-does-google-authenticator-or-other-types-of-2-factor-authenticators-work)
-- [Haqiqiy dunyo misollari](#real-world-case-studies)
- - [Netflixning Tech Stacki](#netflixs-tech-stack)
- - [Twitter arxitekturasi 2022](#twitter-architecture-2022)
- - [Oxirgi 15 yil ichida Airbnb mikroservis arxitekturasining evolyutsiyasi](#evolution-of-airbnbs-microservice-architecture-over-the-past-15-years)
- - [Monorepo va mikrorepo.](#monorepo-vs-microrepo)
- - [Stack Overflow veb-saytini qanday loyihalashtirasiz?](#how-will-you-design-the-stack-overflow-website)
- - [Nima uchun Amazon Prime Video monitoringi serversizdan monolitga o'tdi? Qanday qilib 90% xarajatlarni tejash mumkin?](#why-did-amazon-prime-video-monitoring-move-from-serverless-to-monolithic-how-can-it-save-90-cost)
- - [Disney Hotstar turnir davomida 5 milliard kulgichni qanday suratga oladi?](#how-does-disney-hotstar-capture-5-billion-emojis-during-a-tournament)
- - [Discord qanday qilib trillionlab xabarlarni saqlaydi](#how-discord-stores-trillions-of-messages)
- - [YouTube, TikTok live yoki Twitch-da jonli video oqimlari qanday ishlaydi?](#how-do-video-live-streamings-work-on-youtube-tiktok-live-or-twitch)
+ - [Linux fayl tizimi tushuntirildi](#linux-fayl-tizimi-tushuntirildi)
+ - [Siz bilishingiz kerak bo'lgan 18 ta eng ko'p ishlatiladigan Linux buyruqlari](#siz-bilishingiz-kerak-bolgan-18-ta-eng-kop-ishlatiladigan-linux-buyruqlari)
+- [Xavfsizlik](#xavfsizlik)
+ - [HTTPS qanday ishlaydi?](#https-qanday-ishlaydi)
+ - [Oauth 2.0 oddiy shartlar bilan tushuntirilgan.](#oauth-20-oddiy-shartlar-bilan-tushuntirilgan)
+ - [Autentifikatsiya mexanizmlarining 4 ta eng yaxshi shakllari](#autentifikatsiya-mexanizmlarining-4-ta-eng-yaxshi-shakllari)
+ - [Sessiya, cookie, JWT, token, SSO va OAuth 2.0 - ular nima?](#sessiya-cookie-jwt-token-sso-va-oauth-20---ular-nima)
+ - [Ma'lumotlar bazasida parollarni qanday xavfsiz saqlash va parolni qanday tekshirish mumkin?](#malumotlar-bazasida-parollarni-qanday-xavfsiz-saqlash-va-parolni-qanday-tekshirish-mumkin)
+ - [10 yoshli bolaga JSON Web Token (JWT) haqida tushuntirish](#10-yoshli-bolaga-json-web-token-jwt-haqida-tushuntirish)
+ - [Google Authenticator (yoki 2 faktorli autentifikatsiyaning boshqa turlari) qanday ishlaydi?](#google-authenticator-yoki-2-faktorli-autentifikatsiyaning-boshqa-turlari-qanday-ishlaydi)
+- [Haqiqiy dunyo misollari](#haqiqiy-dunyo-misollari)
+ - [Netflixning Tech Stacki](#netflixning-tech-stacki)
+ - [Twitter arxitekturasi 2022](#twitter-arxitekturasi-2022)
+ - [Oxirgi 15 yil ichida Airbnb mikroservis arxitekturasining evolyutsiyasi](#oxirgi-15-yil-ichida-airbnb-mikroservis-arxitekturasining-evolyutsiyasi)
+ - [Monorepo va mikrorepo.](#monorepo-va-mikrorepo)
+ - [Stack Overflow veb-saytini qanday loyihalashtirasiz?](#stack-overflow-veb-saytini-qanday-loyihalashtirasiz)
+ - [Nima uchun Amazon Prime Video monitoringi serversizdan monolitga o'tdi? Qanday qilib 90% xarajatlarni tejash mumkin?](#nima-uchun-amazon-prime-video-monitoringi-serversizdan-monolitga-otdi-qanday-qilib-90-xarajatlarni-tejash-mumkin)
+ - [Disney Hotstar turnir davomida 5 milliard kulgichni qanday suratga oladi?](#disney-hotstar-turnir-davomida-5-milliard-kulgichni-qanday-suratga-oladi)
+ - [Discord qanday qilib trillionlab xabarlarni saqlaydi?](#discord-qanday-qilib-trillionlab-xabarlarni-saqlaydi)
+ - [YouTube, TikTok live yoki Twitch-da jonli video oqimlari qanday ishlaydi?](#youtube-tiktok-live-yoki-twitch-da-jonli-video-oqimlari-qanday-ishlaydi)
@@ -545,43 +545,43 @@ Voqea haqida hisobot: Hodisalar ustuvorlikka ko'ra jo'natiladi va PagerDuty hodi
## Arxitektura naqshlari
### MVC, MVP, MVVM, MVVM-C va VIPER
-These architecture patterns are among the most commonly used in app development, whether on iOS or Android platforms. Developers have introduced them to overcome the limitations of earlier patterns. So, how do they differ?
+Ushbu arxitektura naqshlari iOS yoki Android platformalarida ilovalarni ishlab chiqishda eng ko'p qo'llaniladi. Ishlab chiquvchilar ularni oldingi naqshlarning cheklovlarini yengish uchun taqdim etdilar. Xo'sh, ular qanday farq qiladi?
-- MVC, the oldest pattern, dates back almost 50 years
-- Every pattern has a "view" (V) responsible for displaying content and receiving user input
-- Most patterns include a "model" (M) to manage business data
-- "Controller," "presenter," and "view-model" are translators that mediate between the view and the model ("entity" in the VIPER pattern)
+- MVC, eng qadimgi naqsh deyarli 50 yil oldin paydo bo'lgan
+- Har bir naqsh kontentni ko'rsatish va foydalanuvchi ma'lumotlarini qabul qilish uchun javobgar bo'lgan "ko'rinish" (V) ga ega
+- Aksariyat naqshlar biznes ma'lumotlarini boshqarish uchun "model" (M) ni o'z ichiga oladi
+- "Controller", "presenter" va "view-model" ko'rinish va model o'rtasida vositachilik qiluvchi tarjimonlardir (VIPER naqshidagi "obyekt")
### Har bir dasturchi bilishi kerak bo'lgan 18 ta asosiy dizayn naqshlari
-Patterns are reusable solutions to common design problems, resulting in a smoother, more efficient development process. They serve as blueprints for building better software structures. These are some of the most popular patterns:
+Naqshlar umumiy dizayn muammolariga qayta foydalanish mumkin bo'lgan echimlar bo'lib, natijada yanada silliq va samaraliroq ishlab chiqish jarayoniga olib keladi. Ular yaxshi dasturiy tuzilmalarni yaratish uchun rejalar bo'lib xizmat qiladi. Bu eng mashhur naqshlardan ba'zilari:
-- Abstract Factory: Family Creator - Makes groups of related items.
-- Builder: Lego Master - Builds objects step by step, keeping creation and appearance separate.
-- Prototype: Clone Maker - Creates copies of fully prepared examples.
-- Singleton: One and Only - A special class with just one instance.
-- Adapter: Universal Plug - Connects things with different interfaces.
-- Bridge: Function Connector - Links how an object works to what it does.
-- Composite: Tree Builder - Forms tree-like structures of simple and complex parts.
-- Decorator: Customizer - Adds features to objects without changing their core.
-- Facade: One-Stop-Shop - Represents a whole system with a single, simplified interface.
-- Flyweight: Space Saver - Shares small, reusable items efficiently.
-- Proxy: Stand-In Actor - Represents another object, controlling access or actions.
-- Chain of Responsibility: Request Relay - Passes a request through a chain of objects until handled.
-- Command: Task Wrapper - Turns a request into an object, ready for action.
-- Iterator: Collection Explorer - Accesses elements in a collection one by one.
-- Mediator: Communication Hub - Simplifies interactions between different classes.
-- Memento: Time Capsule - Captures and restores an object's state.
-- Observer: News Broadcaster - Notifies classes about changes in other objects.
-- Visitor: Skillful Guest - Adds new operations to a class without altering it.
+- Abstract Factory: Family Creator - tegishli elementlar guruhlarini yaratadi.
+- Quruvchi: Lego Master - yaratilish va tashqi ko'rinishini alohida saqlagan holda ob'ektlarni bosqichma-bosqich quradi.
+- Prototip: Clone Maker - to'liq tayyorlangan misollarning nusxalarini yaratadi.
+- Singleton: One and Only - Faqat bitta misolga ega maxsus sinf.
+- Adapter: Universal Plug - turli interfeyslarga ega narsalarni ulaydi.
+- Ko'prik: Funktsiya ulagichi - ob'ekt qanday ishlashini u nima bilan bog'laydi.
+- Kompozit: Tree Builder - oddiy va murakkab qismlarning daraxtga o'xshash tuzilmalarini hosil qiladi.
+- Dekorator: moslashtiruvchi - ob'ektlarning asosiy qismini o'zgartirmasdan ularga xususiyatlar qo'shadi.
+- Fasad: Yagona oyna - yagona, soddalashtirilgan interfeysga ega butun tizimni ifodalaydi.
+- Flyweight: Space Saver - kichik, qayta foydalanish mumkin bo'lgan narsalarni samarali taqsimlaydi.
+- Proksi: Stand-In Actor - kirish yoki harakatlarni boshqaradigan boshqa ob'ektni ifodalaydi.
+- Mas'uliyat zanjiri: so'rov o'tkazmasi - so'rovni ko'rib chiqilgunga qadar ob'ektlar zanjiri orqali o'tkazadi.
+- Buyruq: Task Wrapper - so'rovni harakatga tayyor ob'ektga aylantiradi.
+- Iterator: Collection Explorer - To'plamdagi elementlarga birma-bir murojaat qiladi.
+- Mediator: Communication Hub - turli sinflar o'rtasidagi o'zaro aloqalarni soddalashtiradi.
+- Yodgorlik: Vaqt kapsulasi - ob'ekt holatini suratga oladi va tiklaydi.
+- Observer: News Broadcaster - boshqa ob'ektlardagi o'zgarishlar haqida sinflarni xabardor qiladi.
+- Mehmon: Mohir mehmon - sinfni o'zgartirmasdan unga yangi operatsiyalar qo'shadi.
## Ma'lumotlar bazasi
@@ -591,83 +591,83 @@ Patterns are reusable solutions to common design problems, resulting in a smooth
-Choosing the right database for your project is a complex task. Many database options, each suited to distinct use cases, can quickly lead to decision fatigue.
+Loyihangiz uchun to'g'ri ma'lumotlar bazasini tanlash murakkab vazifadir. Har biri alohida foydalanish holatlariga mos keladigan ko'plab ma'lumotlar bazasi variantlari tezda qaror qabul qilishning charchashiga olib kelishi mumkin.
-We hope this cheat sheet provides high-level direction to pinpoint the right service that aligns with your project's needs and avoid potential pitfalls.
+Umid qilamizki, ushbu hiyla varaqasi loyihangiz ehtiyojlariga mos keladigan to'g'ri xizmatni aniqlash va yuzaga kelishi mumkin bo'lgan tuzoqlardan qochish uchun yuqori darajadagi yo'nalish beradi.
-Note: Google has limited documentation for their database use cases. Even though we did our best to look at what was available and arrived at the best option, some of the entries may need to be more accurate.
+Eslatma: Google maʼlumotlar bazasidan foydalanish holatlari uchun cheklangan hujjatlarga ega. Garchi biz mavjud bo'lgan narsalarni ko'rib chiqish va eng yaxshi variantni topish uchun qo'limizdan kelganini qilgan bo'lsak ham, ba'zi yozuvlar aniqroq bo'lishi kerak bo'lishi mumkin.
### Ma'lumotlar bazalaringizni quvvatlantiradigan 8 ta ma'lumotlar tuzilmasi
-The answer will vary depending on your use case. Data can be indexed in memory or on disk. Similarly, data formats vary, such as numbers, strings, geographic coordinates, etc. The system might be write-heavy or read-heavy. All of these factors affect your choice of database index format.
+Javob sizning foydalanish holatingizga qarab farq qiladi. Ma'lumotlar xotirada yoki diskda indekslanishi mumkin. Xuddi shunday, ma'lumotlar formatlari ham farqlanadi, masalan, raqamlar, satrlar, geografik koordinatalar va boshqalar. Tizim og'ir yozish yoki o'qish uchun og'ir bo'lishi mumkin. Bu omillarning barchasi ma'lumotlar bazasi indeksi formatini tanlashga ta'sir qiladi.
-The following are some of the most popular data structures used for indexing data:
+Quyida ma'lumotlarni indekslash uchun ishlatiladigan eng mashhur ma'lumotlar tuzilmalari keltirilgan:
-- Skiplist: a common in-memory index type. Used in Redis
-- Hash index: a very common implementation of the “Map” data structure (or “Collection”)
-- SSTable: immutable on-disk “Map” implementation
-- LSM tree: Skiplist + SSTable. High write throughput
-- B-tree: disk-based solution. Consistent read/write performance
-- Inverted index: used for document indexing. Used in Lucene
-- Suffix tree: for string pattern search
-- R-tree: multi-dimension search, such as finding the nearest neighbor
+- Skiplist: umumiy xotiradagi indeks turi. Redisda ishlatiladi
+- Xesh indeksi: "Xarita" ma'lumotlar strukturasining (yoki "To'plam") juda keng tarqalgan qo'llanilishi.
+- SSTable: o'zgarmas diskda "Xarita" ni amalga oshirish
+- LSM daraxti: Skiplist + SSTable. Yuqori yozish qobiliyati
+- B-daraxt: diskga asoslangan yechim. Doimiy o'qish/yozish samaradorligi
+- Inverted indeks: hujjatlarni indekslash uchun ishlatiladi. Lucenda ishlatiladi
+- Suffiks daraxti: qator namunalarini qidirish uchun
+- R-daraxt: ko'p o'lchovli qidiruv, masalan, eng yaqin qo'shnini topish
### Ma'lumotlar bazasida SQL operatori qanday bajariladi?
-The diagram below shows the process. Note that the architectures for different databases are different, the diagram demonstrates some common designs.
+Quyidagi diagrammada jarayon ko'rsatilgan. E'tibor bering, turli xil ma'lumotlar bazalari uchun arxitekturalar har xil, diagrammada ba'zi umumiy dizaynlar ko'rsatilgan.
-Step 1 - A SQL statement is sent to the database via a transport layer protocol (e.g.TCP).
+1-qadam - SQL bayonoti ma'lumotlar bazasiga transport qatlami protokoli (masalan, TCP) orqali yuboriladi.
-Step 2 - The SQL statement is sent to the command parser, where it goes through syntactic and semantic analysis, and a query tree is generated afterward.
+2-qadam - SQL bayonoti buyruq tahlilchisiga yuboriladi, u erda sintaktik va semantik tahlildan o'tadi va keyin so'rovlar daraxti hosil bo'ladi.
-Step 3 - The query tree is sent to the optimizer. The optimizer creates an execution plan.
+3-qadam - so'rovlar daraxti optimallashtiruvchiga yuboriladi. Optimallashtiruvchi ijro rejasini yaratadi.
-Step 4 - The execution plan is sent to the executor. The executor retrieves data from the execution.
+4-bosqich - ijro rejasi ijrochiga yuboriladi. Ijrochi ijrodan ma'lumotlarni oladi.
-Step 5 - Access methods provide the data fetching logic required for execution, retrieving data from the storage engine.
+5-qadam - Kirish usullari bajarish uchun zarur bo'lgan ma'lumotlarni olish mantiqini ta'minlaydi, ma'lumotlarni saqlash mexanizmidan oladi.
-Step 6 - Access methods decide whether the SQL statement is read-only. If the query is read-only (SELECT statement), it is passed to the buffer manager for further processing. The buffer manager looks for the data in the cache or data files.
+6-qadam - Kirish usullari SQL bayonotining faqat o'qish uchun ekanligini hal qiladi. Agar so'rov faqat o'qish uchun bo'lsa (SELECT iborasi), u keyingi ishlov berish uchun bufer menejeriga uzatiladi. Bufer menejeri kesh yoki ma'lumotlar fayllaridagi ma'lumotlarni qidiradi.
-Step 7 - If the statement is an UPDATE or INSERT, it is passed to the transaction manager for further processing.
+7-qadam - Agar bayonot UPDATE yoki INSERT bo'lsa, u keyingi qayta ishlash uchun tranzaksiya menejeriga uzatiladi.
-Step 8 - During a transaction, the data is in lock mode. This is guaranteed by the lock manager. It also ensures the transaction’s ACID properties.
+8-qadam - Tranzaksiya paytida ma'lumotlar blokirovka rejimida. Bu qulflash menejeri tomonidan kafolatlanadi. Shuningdek, u tranzaksiyaning ACID xususiyatlarini ta'minlaydi.
### CAP teoremasi
-The CAP theorem is one of the most famous terms in computer science, but I bet different developers have different understandings. Let’s examine what it is and why it can be confusing.
+CAP teoremasi kompyuter fanidagi eng mashhur atamalardan biridir, ammo men turli ishlab chiquvchilar turli xil tushunchalarga ega ekanligiga aminman. Keling, bu nima ekanligini va nima uchun bu chalkash bo'lishi mumkinligini ko'rib chiqaylik.
-CAP theorem states that a distributed system can't provide more than two of these three guarantees simultaneously.
+CAP teoremasi taqsimlangan tizim bir vaqtning o'zida ushbu uchta kafolatdan ikkitadan ko'pini ta'minlay olmasligini bildiradi.
-**Consistency**: consistency means all clients see the same data at the same time no matter which node they connect to.
+**Muvofiqlik**: izchillik barcha mijozlar qaysi tugunga ulanishidan qat'i nazar, bir vaqtning o'zida bir xil ma'lumotlarni ko'rishini anglatadi.
-**Availability**: availability means any client that requests data gets a response even if some of the nodes are down.
+**Mavjudlik**: mavjudlik degani, ma'lumotlarni so'ragan har qanday mijoz, hatto ba'zi tugunlar ishlamay qolgan bo'lsa ham, javob oladi.
-**Partition Tolerance**: a partition indicates a communication break between two nodes. Partition tolerance means the system continues to operate despite network partitions.
+**Bo'limga tolerantlik**: bo'lim ikki tugun o'rtasidagi aloqa uzilishini bildiradi. Bo'limga tolerantlik tizim tarmoq bo'limlariga qaramay ishlashda davom etishini anglatadi.
-The “2 of 3” formulation can be useful, **but this simplification could be misleading**.
+"2 dan 3" formulasi foydali bo'lishi mumkin, **ammo bu soddalashtirish noto'g'ri bo'lishi mumkin**.
-1. Picking a database is not easy. Justifying our choice purely based on the CAP theorem is not enough. For example, companies don't choose Cassandra for chat applications simply because it is an AP system. There is a list of good characteristics that make Cassandra a desirable option for storing chat messages. We need to dig deeper.
+1. Ma'lumotlar bazasini tanlash oson emas. Bizning tanlovimizni faqat CAP teoremasi asosida asoslash etarli emas. Masalan, kompaniyalar AP tizimi bo'lgani uchun chat ilovalari uchun Cassandrani tanlamaydi.Cassandrani chat xabarlarini saqlash uchun kerakli variantga aylantiradigan yaxshi xususiyatlar ro'yxati mavjud. Biz chuqurroq qazishimiz kerak.
-2. “CAP prohibits only a tiny part of the design space: perfect availability and consistency in the presence of partitions, which are rare”. Quoted from the paper: CAP Twelve Years Later: How the “Rules” Have Changed.
+2. "CAP dizayn maydonining faqat kichik bir qismini taqiqlaydi: kamdan-kam uchraydigan qismlar mavjud bo'lganda mukammal mavjudlik va mustahkamlik". Maqoladan iqtibos: O'n ikki yil o'tib CAP: "Qoidalar" qanday o'zgargan.
-3. The theorem is about 100% availability and consistency. A more realistic discussion would be the trade-offs between latency and consistency when there is no network partition. See PACELC theorem for more details.
+3. Teorema taxminan 100% mavjudlik va izchillikdir. Tarmoq bo'limi bo'lmaganda kechikish va izchillik o'rtasidagi kelishuv yanada realroq muhokama bo'ladi. Batafsil ma'lumot uchun PACELC teoremasiga qarang.
-**Is the CAP theorem actually useful?**
+**CAP teoremasi haqiqatan ham foydalimi?**
-I think it is still useful as it opens our minds to a set of tradeoff discussions, but it is only part of the story. We need to dig deeper when picking the right database.
+O'ylaymanki, bu hali ham foydali, chunki u bizning fikrimizni bir qator munozaralar uchun ochadi, ammo bu hikoyaning faqat bir qismi. To'g'ri ma'lumotlar bazasini tanlashda biz chuqurroq qazishimiz kerak.
### Xotira va saqlash turlari
@@ -682,137 +682,136 @@ I think it is still useful as it opens our minds to a set of tradeoff discussion
-SQL statements are executed by the database system in several steps, including:
+SQL bayonotlari ma'lumotlar bazasi tizimi tomonidan bir necha bosqichda amalga oshiriladi, jumladan:
-- Parsing the SQL statement and checking its validity
-- Transforming the SQL into an internal representation, such as relational algebra
-- Optimizing the internal representation and creating an execution plan that utilizes index information
-- Executing the plan and returning the results
+- SQL bayonotini tahlil qilish va uning haqiqiyligini tekshirish
+- SQLni relyatsion algebra kabi ichki tasvirga aylantirish
+- Ichki vakillikni optimallashtirish va indeks ma'lumotlaridan foydalanadigan ijro rejasini yaratish
+- Rejani bajarish va natijalarni qaytarish
-The execution of SQL is highly complex and involves many considerations, such as:
+SQL-ni bajarish juda murakkab va ko'plab fikrlarni o'z ichiga oladi, masalan:
-- The use of indexes and caches
-- The order of table joins
-- Concurrency control
-- Transaction management
+- Indekslar va keshlardan foydalanish
+- Jadvalni birlashtirish tartibi
+- Parametrlarni nazorat qilish
+- Tranzaksiyalarni boshqarish
### SQL tili
-In 1986, SQL (Structured Query Language) became a standard. Over the next 40 years, it became the dominant language for relational database management systems. Reading the latest standard (ANSI SQL 2016) can be time-consuming. How can I learn it?
+1986 yilda SQL (Structured Query Language) standartga aylandi. Keyingi 40 yil ichida u relyatsion ma'lumotlar bazasini boshqarish tizimlari uchun dominant tilga aylandi. Eng so'nggi standartni (ANSI SQL 2016) o'qish ko'p vaqt talab qilishi mumkin. Uni qanday o'rganishim mumkin?
-There are 5 components of the SQL language:
+SQL tilining 5 ta komponenti mavjud:
-- DDL: data definition language, such as CREATE, ALTER, DROP
-- DQL: data query language, such as SELECT
-- DML: data manipulation language, such as INSERT, UPDATE, DELETE
-- DCL: data control language, such as GRANT, REVOKE
-- TCL: transaction control language, such as COMMIT, ROLLBACK
+- DDL: CREATE, ALTER, DROP kabi ma'lumotlarni aniqlash tili
+- DQL: ma'lumotlar so'rovi tili, masalan, SELECT
+- DML: INSERT, UPDATE, DELETE kabi ma'lumotlarni manipulyatsiya qilish tili
+- DCL: ma'lumotlarni boshqarish tili, masalan, GRANT, REVOKE
+- TCL: COMMIT, ROLLBACK kabi tranzaktsiyalarni boshqarish tili
-For a backend engineer, you may need to know most of it. As a data analyst, you may need to have a good understanding of DQL. Select the topics that are most relevant to you.
+Backend muhandisi uchun siz uning ko'p qismini bilishingiz kerak bo'lishi mumkin. Ma'lumotlar tahlilchisi sifatida siz DQL haqida yaxshi tushunchaga ega bo'lishingiz kerak bo'lishi mumkin. Sizga eng mos keladigan mavzularni tanlang.
## Kesh
-### Data is cached everywhere
+### Ma'lumotlar hamma joyda keshlangan
-This diagram illustrates where we cache data in a typical architecture.
+Ushbu diagramma odatiy arxitekturada ma'lumotlarni keshlash joyini ko'rsatadi.
-There are **multiple layers** along the flow.
+Oqim bo'ylab **bir nechta qatlamlar** mavjud.
-1. Client apps: HTTP responses can be cached by the browser. We request data over HTTP for the first time, and it is returned with an expiry policy in the HTTP header; we request data again, and the client app tries to retrieve the data from the browser cache first.
-2. CDN: CDN caches static web resources. The clients can retrieve data from a CDN node nearby.
-3. Load Balancer: The load Balancer can cache resources as well.
-4. Messaging infra: Message brokers store messages on disk first, and then consumers retrieve them at their own pace. Depending on the retention policy, the data is cached in Kafka clusters for a period of time.
-5. Services: There are multiple layers of cache in a service. If the data is not cached in the CPU cache, the service will try to retrieve the data from memory. Sometimes the service has a second-level cache to store data on disk.
-6. Distributed Cache: Distributed cache like Redis holds key-value pairs for multiple services in memory. It provides much better read/write performance than the database.
-7. Full-text Search: we sometimes need to use full-text searches like Elastic Search for document search or log search. A copy of data is indexed in the search engine as well.
-8. Database: Even in the database, we have different levels of caches:
-- WAL(Write-ahead Log): data is written to WAL first before building the B tree index
-- Bufferpool: A memory area allocated to cache query results
-- Materialized View: Pre-compute query results and store them in the database tables for better query performance
-- Transaction log: record all the transactions and database updates
-- Replication Log: used to record the replication state in a database cluster
+1. Mijoz ilovalari: HTTP javoblari brauzer tomonidan keshlanishi mumkin. Biz HTTP orqali birinchi marta maʼlumot soʻrayapmiz va ular HTTP sarlavhasida amal qilish muddati siyosati bilan qaytariladi; biz yana ma'lumotlarni so'raymiz va mijoz ilovasi avval brauzer keshidan ma'lumotlarni olishga harakat qiladi.
+2. CDN: CDN statik veb-resurslarni keshlaydi. Mijozlar yaqin atrofdagi CDN tugunidan ma'lumotlarni olishlari mumkin.
+3. Load Balancer: Load Balancer resurslarni ham keshlashi mumkin.
+4. Xabarlar infratuzilmasi: Xabar brokerlari xabarlarni avval diskda saqlaydi va keyin iste'molchilar ularni o'z tezligida oladilar. Saqlash siyosatiga qarab, ma'lumotlar ma'lum vaqt davomida Kafka klasterlarida keshlanadi.
+5. Xizmatlar: Xizmatda keshning bir nechta qatlamlari mavjud. Agar ma'lumotlar CPU keshida keshlanmagan bo'lsa, xizmat ma'lumotlarni xotiradan olishga harakat qiladi. Ba'zan xizmatda ma'lumotlarni diskda saqlash uchun ikkinchi darajali kesh mavjud.
+6. Taqsimlangan kesh: Redis kabi taqsimlangan kesh xotirada bir nechta xizmatlar uchun kalit-qiymat juftlarini saqlaydi. Bu ma'lumotlar bazasiga qaraganda ancha yaxshi o'qish/yozish unumdorligini ta'minlaydi.
+7. To'liq matnli qidiruv: biz ba'zan hujjat qidirish yoki jurnaldan qidirish uchun Elastik qidiruv kabi to'liq matnli qidiruvlardan foydalanishimiz kerak. Ma'lumotlarning nusxasi qidiruv tizimida ham indekslanadi.
+8. Ma'lumotlar bazasi: Hatto ma'lumotlar bazasida ham bizda turli darajadagi keshlar mavjud:
+- WAL (Oldindan yozish jurnali): ma'lumotlar B daraxti indeksini yaratishdan oldin WAL-ga yoziladi
+- Bufferpool: Kesh so'rovi natijalari uchun ajratilgan xotira maydoni
+- Materiallashtirilgan ko'rinish: so'rov natijalarini oldindan hisoblab chiqing va so'rovlar yaxshi ishlashi uchun ularni ma'lumotlar bazasi jadvallarida saqlang
+- Tranzaksiya jurnali: barcha tranzaktsiyalar va ma'lumotlar bazasi yangilanishlarini yozib oling
+- Replikatsiya jurnali: ma'lumotlar bazasi klasterida replikatsiya holatini yozish uchun ishlatiladi
-### Why is Redis so fast?
+### Nima uchun Redis juda tez?
-There are 3 main reasons as shown in the diagram below.
+Quyidagi diagrammada ko'rsatilgandek 3 ta asosiy sabab bor.
-1. Redis is a RAM-based data store. RAM access is at least 1000 times faster than random disk access.
-2. Redis leverages IO multiplexing and single-threaded execution loop for execution efficiency.
-3. Redis leverages several efficient lower-level data structures.
+1. Redis - bu RAMga asoslangan ma'lumotlar do'koni. RAMga kirish tasodifiy diskdan foydalanishdan kamida 1000 marta tezroq.
+2. Redis ijro samaradorligi uchun IO multiplekslash va bitta torli bajarish siklidan foydalanadi.
+3. Redis bir nechta samarali quyi darajadagi ma'lumotlar tuzilmalaridan foydalanadi.
-Question: Another popular in-memory store is Memcached. Do you know the differences between Redis and Memcached?
+Savol: Yana bir mashhur xotira do'koni - Memcached. Redis va Memcached o'rtasidagi farqni bilasizmi?
-You might have noticed the style of this diagram is different from my previous posts. Please let me know which one you prefer.
+Siz ushbu diagrammaning uslubi oldingi postlarimdan farq qilganini payqagan bo'lishingiz mumkin. Iltimos, qaysi birini afzal ko'rishingizni menga xabar bering.
-### How can Redis be used?
+### Redisdan qanday foydalanish mumkin?
-There is more to Redis than just caching.
+Redisda keshlashdan ko'ra ko'proq narsa bor.
-Redis can be used in a variety of scenarios as shown in the diagram.
+Diagrammada ko'rsatilganidek, Redis turli stsenariylarda ishlatilishi mumkin.
-- Session
+- Sessiya
- We can use Redis to share user session data among different services.
+ Biz Redisdan foydalanuvchi sessiyasi ma'lumotlarini turli xizmatlar o'rtasida almashish uchun foydalanishimiz mumkin.
-- Cache
+- Kesh
- We can use Redis to cache objects or pages, especially for hotspot data.
+ Ob'ektlar yoki sahifalarni keshlash uchun Redis-dan foydalanishimiz mumkin, ayniqsa hotspot ma'lumotlari uchun.
-- Distributed lock
+- Tarqalgan qulf
- We can use a Redis string to acquire locks among distributed services.
+ Tarqatilgan xizmatlar orasida qulflarni olish uchun Redis qatoridan foydalanishimiz mumkin.
-- Counter
+- Hisoblagich
- We can count how many likes or how many reads for articles.
+ Biz maqolalar uchun qancha yoqtirish yoki qancha o'qishni hisoblashimiz mumkin.
-- Rate limiter
+- Tarif cheklovchisi
- We can apply a rate limiter for certain user IPs.
+ Biz ma'lum foydalanuvchi IP-lari uchun tarif cheklovchisini qo'llashimiz mumkin.
- Global ID generator
- We can use Redis Int for global ID.
+ Global ID uchun Redis Int dan foydalanishimiz mumkin.
-- Shopping cart
+- Xarid savati
- We can use Redis Hash to represent key-value pairs in a shopping cart.
+ Xarid qilish savatidagi kalit-qiymat juftligini ko'rsatish uchun Redis Hash-dan foydalanishimiz mumkin.
-- Calculate user retention
+- Foydalanuvchini ushlab turishni hisoblash
- We can use Bitmap to represent the user login daily and calculate user retention.
+ Bitmap-dan foydalanuvchi loginini har kuni ko'rsatish va foydalanuvchini ushlab turishini hisoblash uchun foydalanishimiz mumkin.
-- Message queue
+- Xabar navbati
- We can use List for a message queue.
+ Biz xabarlar navbati uchun List-dan foydalanishimiz mumkin
-- Ranking
+- Reyting
- We can use ZSet to sort the articles.
+ Maqolalarni saralash uchun ZSet dan foydalanishimiz mumkin.
-### Top caching strategies
+### Eng yaxshi keshlash strategiyalari
-Designing large-scale systems usually requires careful consideration of caching.
-Below are five caching strategies that are frequently utilized.
+Katta miqyosli tizimlarni loyihalash odatda keshlashni diqqat bilan ko'rib chiqishni talab qiladi. Quyida tez-tez ishlatiladigan beshta keshlash strategiyasi keltirilgan.
@@ -820,55 +819,55 @@ Below are five caching strategies that are frequently utilized.
-## Microservice architecture
+## Mikroservis arxitekturasi
-### What does a typical microservice architecture look like?
+### Oddiy mikroservis arxitekturasi nimaga o'xshaydi?
-The diagram below shows a typical microservice architecture.
+Quyidagi diagrammada mikroservisning odatiy arxitekturasi ko'rsatilgan.
-- Load Balancer: This distributes incoming traffic across multiple backend services.
-- CDN (Content Delivery Network): CDN is a group of geographically distributed servers that hold static content for faster delivery. The clients look for content in CDN first, then progress to backend services.
-- API Gateway: This handles incoming requests and routes them to the relevant services. It talks to the identity provider and service discovery.
-- Identity Provider: This handles authentication and authorization for users.
-- Service Registry & Discovery: Microservice registration and discovery happen in this component, and the API gateway looks for relevant services in this component to talk to.
-- Management: This component is responsible for monitoring the services.
-- Microservices: Microservices are designed and deployed in different domains. Each domain has its own database. The API gateway talks to the microservices via REST API or other protocols, and the microservices within the same domain talk to each other using RPC (Remote Procedure Call).
+- Load Balancer: Bu kiruvchi trafikni bir nechta backend xizmatlariga taqsimlaydi.
+- CDN (Content Delivery Network): CDN bu tezroq yetkazib berish uchun statik tarkibga ega bo'lgan geografik taqsimlangan serverlar guruhidir. Mijozlar avval CDN-da tarkibni qidiradi, keyin esa backend xizmatlariga o'tadi.
+- API Gateway: Bu kiruvchi so'rovlarni ko'rib chiqadi va ularni tegishli xizmatlarga yo'naltiradi. U identifikatsiya provayderi va xizmat kashfiyoti bilan gaplashadi.
+- Identifikatsiya provayderi: Bu foydalanuvchilar uchun autentifikatsiya va avtorizatsiya bilan shug'ullanadi.
+- Xizmat reestri va kashfiyot: Mikroservisni ro'yxatdan o'tkazish va ochish ushbu komponentda sodir bo'ladi va API shlyuzi suhbatlashish uchun ushbu komponentda tegishli xizmatlarni qidiradi.
+- Boshqaruv: Ushbu komponent xizmatlarni kuzatish uchun javobgardir.
+- Mikroservislar: Mikroservislar turli sohalarda ishlab chiqilgan va joylashtirilgan. Har bir domen o'z ma'lumotlar bazasiga ega. API shlyuzi REST API yoki boshqa protokollar orqali mikroservislar bilan gaplashadi va bir domendagi mikroservislar RPC (Remote Procedure Call) yordamida bir-biri bilan gaplashadi.
-Benefits of microservices:
+Mikroservislarning afzalliklari:
-- They can be quickly designed, deployed, and horizontally scaled.
-- Each domain can be independently maintained by a dedicated team.
-- Business requirements can be customized in each domain and better supported, as a result.
+- Ular tezda ishlab chiqilishi, joylashtirilishi va gorizontal ravishda o'lchanishi mumkin.
+- Har bir domen maxsus guruh tomonidan mustaqil ravishda saqlanishi mumkin.
+- Biznes talablari har bir domenda moslashtirilishi va natijada yaxshiroq qo'llab-quvvatlanishi mumkin.
-### Microservice Best Practices
+### Mikroservisning eng yaxshi amaliyotlari
-A picture is worth a thousand words: 9 best practices for developing microservices.
+Rasm ming so'zga arziydi: mikroservislarni ishlab chiqish bo'yicha 9 ta eng yaxshi amaliyot.
-When we develop microservices, we need to follow the following best practices:
+Mikroservislarni ishlab chiqishda biz quyidagi eng yaxshi amaliyotlarga amal qilishimiz kerak:
-1. Use separate data storage for each microservice
-2. Keep code at a similar level of maturity
-3. Separate build for each microservice
-4. Assign each microservice with a single responsibility
-5. Deploy into containers
-6. Design stateless services
-7. Adopt domain-driven design
-8. Design micro frontend
-9. Orchestrating microservices
+1. Har bir mikroxizmat uchun alohida maʼlumotlarni saqlashdan foydalaning
+2. Kodni xuddi shunday etuklik darajasida saqlang
+3. Har bir mikroservis uchun alohida tuzilma
+4. Har bir mikroxizmatni bitta mas'uliyat bilan tayinlang responsibility
+5. Konteynerlarga joylashtiring
+6. Fuqaroligi bo'lmagan xizmatlarni loyihalash
+7. Domenga asoslangan dizaynni qabul qiling
+8. Mikro frontendni loyihalash
+9. Mikroservislarni tashkil qilish
-### What tech stack is commonly used for microservices?
+### Mikroservislar uchun qanday texnologik stek ishlatiladi?
-Below you will find a diagram showing the microservice tech stack, both for the development phase and for production.
+Quyida siz mikroservis texnologiyalari stekini ishlab chiqish bosqichida ham, ishlab chiqarishda ham ko'rsatadigan diagrammani topasiz.
@@ -877,64 +876,64 @@ Below you will find a diagram showing the microservice tech stack, both for the
▶️ 𝐏𝐫𝐞-𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧
-- Define API - This establishes a contract between frontend and backend. We can use Postman or OpenAPI for this.
-- Development - Node.js or react is popular for frontend development, and java/python/go for backend development. Also, we need to change the configurations in the API gateway according to API definitions.
-- Continuous Integration - JUnit and Jenkins for automated testing. The code is packaged into a Docker image and deployed as microservices.
+- Define API - Bu frontend va backend o'rtasida shartnoma o'rnatadi. Buning uchun Postman yoki OpenAPI dan foydalanishimiz mumkin.
+- Ishlab chiqish - Node.js yoki react frontend ishlab chiqish uchun, java/python/go esa backend ishlab chiqish uchun mashhur. Bundan tashqari, API ta'riflariga muvofiq API shlyuzidagi konfiguratsiyalarni o'zgartirishimiz kerak.
+- Uzluksiz integratsiya - avtomatlashtirilgan sinov uchun JUnit va Jenkins. Kod Docker tasviriga qadoqlangan va mikroservislar sifatida joylashtirilgan.
▶️ 𝐏𝐫𝐨𝐝𝐮𝐜𝐭𝐢𝐨𝐧
-- NGinx is a common choice for load balancers. Cloudflare provides CDN (Content Delivery Network).
-- API Gateway - We can use spring boot for the gateway, and use Eureka/Zookeeper for service discovery.
-- The microservices are deployed on clouds. We have options among AWS, Microsoft Azure, or Google GCP.
-Cache and Full-text Search - Redis is a common choice for caching key-value pairs. Elasticsearch is used for full-text search.
-- Communications - For services to talk to each other, we can use messaging infra Kafka or RPC.
-- Persistence - We can use MySQL or PostgreSQL for a relational database, and Amazon S3 for object store. We can also use Cassandra for the wide-column store if necessary.
-- Management & Monitoring - To manage so many microservices, the common Ops tools include Prometheus, Elastic Stack, and Kubernetes.
+- NGinx yuk balanslagichlari uchun keng tarqalgan tanlovdir. Cloudflare CDN (Content Delivery Network) bilan ta'minlaydi.
+- API Gateway - Biz shlyuz uchun bahor yuklashdan foydalanishimiz mumkin va xizmatni aniqlash uchun Eureka/Zookeeper dan foydalanishimiz mumkin.
+- Mikroservislar bulutlarda joylashtirilgan. Bizda AWS, Microsoft Azure yoki Google GCP orasida variantlar mavjud. Kesh va to'liq matnli qidiruv - Redis kalit-qiymat juftlarini keshlash uchun keng tarqalgan tanlovdir. Elasticsearch to'liq matnli qidiruv uchun ishlatiladi.
+- Aloqa - xizmatlar bir-biri bilan gaplashishi uchun biz xabar almashish infra Kafka yoki RPC dan foydalanishimiz mumkin.
+- Qat'iylik - Biz aloqador ma'lumotlar bazasi uchun MySQL yoki PostgreSQL va ob'ektlarni saqlash uchun Amazon S3 dan foydalanishimiz mumkin. Agar kerak bo'lsa, biz Cassandra-dan keng ustunli do'kon uchun ham foydalanishimiz mumkin.
+- Boshqaruv va monitoring - Ko'plab mikroservislarni boshqarish uchun umumiy Ops vositalariga Prometey, Elastic Stack va Kubernetes kiradi.
-### Why is Kafka fast
+### Nega Kafka tez
-There are many design decisions that contributed to Kafka’s performance. In this post, we’ll focus on two. We think these two carried the most weight.
+Kafkaning ishlashiga hissa qo'shgan ko'plab dizayn qarorlari mavjud. Ushbu postda biz ikkitasiga e'tibor qaratamiz. Bizning fikrimizcha, bu ikkisi eng ko'p og'irlikni ko'targan.
-1. The first one is Kafka’s reliance on Sequential I/O.
-2. The second design choice that gives Kafka its performance advantage is its focus on efficiency: zero copy principle.
+1. Birinchisi, Kafkaning Sequential I/U-ga tayanishi.
+2. Kafkaning ishlash ustunligini ta'minlaydigan ikkinchi dizayn tanlovi - bu samaradorlikka e'tibor: nol nusxa ko'chirish printsipi.
-The diagram illustrates how the data is transmitted between producer and consumer, and what zero-copy means.
+Diagrammada ma'lumotlar ishlab chiqaruvchi va iste'molchi o'rtasida qanday uzatilishi va nol nusxasi nimani anglatishini ko'rsatadi.
-- Step 1.1 - 1.3: Producer writes data to the disk
-- Step 2: Consumer reads data without zero-copy
+- 1.1 - 1.3-qadam: Ishlab chiqaruvchi diskka ma'lumotlarni yozadi
+- 2-qadam: Iste'molchi ma'lumotlarni nol nusxasiz o'qiydi
-2.1 The data is loaded from disk to OS cache
+2.1 Ma'lumotlar diskdan OS keshiga yuklanadi
-2.2 The data is copied from OS cache to Kafka application
+2.2 Ma'lumotlar OT keshidan Kafka ilovasiga ko'chiriladi
-2.3 Kafka application copies the data into the socket buffer
+2.3 Kafka ilovasi ma'lumotlarni rozetka buferiga ko'chiradi
-2.4 The data is copied from socket buffer to network card
+2.4 Ma'lumotlar soket buferidan tarmoq kartasiga ko'chiriladi
-2.5 The network card sends data out to the consumer
+2.5 Tarmoq kartasi ma'lumotlarni iste'molchiga yuboradi
-
-- Step 3: Consumer reads data with zero-copy
+- 3-qadam: Iste'molchi ma'lumotlarni nol nusxada o'qiydi
+
+3.1: Ma'lumotlar diskdan OS keshiga yuklanadi
+
+3.2 OT keshi ma'lumotlarni sendfile() buyrug'i orqali to'g'ridan-to'g'ri tarmoq kartasiga ko'chiradi
-3.1: The data is loaded from disk to OS cache
-3.2 OS cache directly copies the data to the network card via sendfile() command
-3.3 The network card sends data out to the consumer
+3.3 Tarmoq kartasi ma'lumotlarni iste'molchiga yuboradi
-Zero copy is a shortcut to save the multiple data copies between application context and kernel context.
+Nolinchi nusxa - dastur konteksti va yadro konteksti o'rtasida bir nechta ma'lumotlar nusxalarini saqlash uchun yorliq.
-## Payment systems
+## To'lov tizimlari
-### How to learn payment systems?
+### To'lov tizimini qanday o'rganish mumkin?
-### Why is the credit card called “the most profitable product in banks”? How does VISA/Mastercard make money?
+### Nima uchun kredit karta "banklardagi eng daromadli mahsulot" deb ataladi? VISA/Mastercard qanday qilib pul ishlaydi?
The diagram below shows the economics of the credit card payment flow.
@@ -960,7 +959,7 @@ Why should the issuing bank be compensated?
- The issuer pays the merchant before the cardholder pays the issuer.
- The issuer has other operating costs, including managing customer accounts, providing statements, fraud detection, risk management, clearing & settlement, etc.
-### How does VISA work when we swipe a credit card at a merchant’s shop?
+### Savdogarlar do'konida kredit kartani o'tkazganimizda VISA qanday ishlaydi?
@@ -997,7 +996,7 @@ Step 4: The card network clears up the transactions from different acquiring ban
In the process, the card network takes on the burden of talking to each bank and receives service fees in return.
-### Payment Systems Around The World Series (Part 1): Unified Payments Interface (UPI) in India
+### Dunyo bo'ylab to'lov tizimlari seriyasi (1-qism): Hindistonda yagona to'lov interfeysi (UPI)
What’s UPI? UPI is an instant real-time payment system developed by the National Payments Corporation of India.
@@ -1014,7 +1013,7 @@ UPI = payment markup language + standard for interoperable payments
## DevOps
-### DevOps vs. SRE vs. Platform Engineering. What is the difference?
+### DevOps va SRE va platforma muhandisligi. Farqi nimada?
The concepts of DevOps, SRE, and Platform Engineering have emerged at different times and have been developed by various individuals and organizations.
@@ -1030,7 +1029,7 @@ Platform Engineering is a more recent concept, building on the foundation of SRE
It's worth noting that while these concepts emerged at different times. They are all related to the broader trend of improving collaboration, automation, and efficiency in software development and operations.
-### What is k8s (Kubernetes)?
+### K8s (Kubernetes) nima?
K8s is a container orchestration system. It is used for container deployment and management. Its design is greatly impacted by Google’s internal system Borg.
@@ -1074,7 +1073,7 @@ The worker node(s) host the Pods that are the components of the application work
Kube-proxy is a network proxy that runs on each node in your cluster. It routes traffic coming into a node from the service. It forwards requests for work to the correct containers.
-### Docker vs. Kubernetes. Which one should we use?
+### Docker va Kubernetes. Qaysi birini ishlatishimiz kerak?
@@ -1099,7 +1098,7 @@ Kubernetes: Kubernetes operates at the cluster level. It manages multiple contai
In short, Docker focuses on containerization and running containers on individual hosts, while Kubernetes specializes in managing and orchestrating containers at scale across a cluster of hosts.
-### How does Docker work?
+### Docker qanday ishlaydi?
The diagram below shows the architecture of Docker and how it works when we run “docker build”, “docker pull”
and “docker run”.
@@ -1132,7 +1131,7 @@ Let’s take the “docker run” command as an example.
## GIT
-### How Git Commands work
+### Git buyruqlari qanday ishlaydi
To begin with, it's essential to identify where our code is stored. The common assumption is that there are only two locations - one on a remote server like Github and the other on our local machine. However, this isn't entirely accurate. Git maintains three local storages on our machine, which means that our code can be found in four places:
@@ -1148,7 +1147,7 @@ To begin with, it's essential to identify where our code is stored. The common a
Most Git commands primarily move files between these four locations.
-### How does Git Work?
+### Git qanday ishlaydi?
The diagram below shows the Git workflow.
@@ -1165,7 +1164,7 @@ The commit is very fast because the operation doesn’t interact with the remote
If the remote repository crashes, the files can be recovered from the local repositories.
-### Git merge vs. Git rebase
+### Git merge va Git rebase]
What are the differences?
@@ -1194,16 +1193,16 @@ Rebase can be dangerous if “the golden rule of git rebase” is not followed.
Never use it on public branches!
-## Cloud Services
+## Bulutli xizmatlar
-### A nice cheat sheet of different cloud services (2023 edition)
+### Turli xil bulut xizmatlarining chiroyli cheat varag'i (2023 yil nashri)
-### What is cloud native?
+### Mahalliy bulut nima?
Below is a diagram showing the evolution of architecture and processes since the 1980s.
@@ -1233,9 +1232,9 @@ Cloud native includes 4 aspects:
The applications are massively deployed on cloud infrastructure instead of self-hosted servers.
-## Developer productivity tools
+## Ishlab chiquvchi mahsuldorlik vositalari
-### Visualize JSON files
+### JSON fayllarini vizualizatsiya qilish
Nested JSON files are hard to read.
@@ -1248,7 +1247,7 @@ Additionally, the generated diagrams can be downloaded as images.
-### Automatically turn code into architecture diagrams
+### Kodni avtomatik ravishda arxitektura diagrammalariga aylantiring
@@ -1266,7 +1265,7 @@ What does it do?
## Linux
-### Linux file system explained
+### Linux fayl tizimi tushuntirildi
@@ -1277,7 +1276,7 @@ The Linux file system used to resemble an unorganized town where individuals con
By implementing a standard like the FHS, software can ensure a consistent layout across various Linux distributions. Nonetheless, not all Linux distributions strictly adhere to this standard. They often incorporate their own unique elements or cater to specific requirements.
To become proficient in this standard, you can begin by exploring. Utilize commands such as "cd" for navigation and "ls" for listing directory contents. Imagine the file system as a tree, starting from the root (/). With time, it will become second nature to you, transforming you into a skilled Linux administrator.
-### 18 Most-used Linux Commands You Should Know
+### Siz bilishingiz kerak bo'lgan 18 ta eng ko'p ishlatiladigan Linux buyruqlari
Linux commands are instructions for interacting with the operating system. They help manage files, directories, system processes, and many other aspects of the system. You need to become familiar with these commands in order to navigate and maintain Linux-based systems efficiently and effectively.
@@ -1307,9 +1306,9 @@ This diagram below shows popular Linux commands:
- ifconfig - Configure network interfaces
- ping - Test network connectivity between hosts
-## Security
+## Xavfsizlik
-### How does HTTPS work?
+### HTTPS qanday ishlaydi?
Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP.) HTTPS transmits encrypted data using Transport Layer Security (TLS.) If the data is hijacked online, all the hijacker gets is binary code.
@@ -1336,7 +1335,7 @@ Why does HTTPS switch to symmetric encryption during data transmission? There ar
2. Server resources: The asymmetric encryption adds quite a lot of mathematical overhead. It is not suitable for data transmissions in long sessions.
-### Oauth 2.0 Explained With Simple Terms.
+### Oauth 2.0 oddiy shartlar bilan tushuntirilgan.
OAuth 2.0 is a powerful and secure framework that allows different applications to securely interact with each other on behalf of users without sharing sensitive credentials.
@@ -1358,7 +1357,7 @@ Accessing User Profile: Apps with an OAuth token can access certain parts of you
Remember, OAuth 2.0 is all about keeping you and your data safe while making your online experiences seamless and hassle-free across different applications and services.
-### Top 4 Forms of Authentication Mechanisms
+### Autentifikatsiya mexanizmlarining 4 ta eng yaxshi shakllari
@@ -1380,7 +1379,7 @@ Remember, OAuth 2.0 is all about keeping you and your data safe while making you
User authentication information is used to verify and grant access to various systems and services
-### Session, cookie, JWT, token, SSO, and OAuth 2.0 - what are they?
+### Sessiya, cookie, JWT, token, SSO va OAuth 2.0 - ular nima?
These terms are all related to user identity management. When you log into a website, you declare who you are (identification). Your identity is verified (authentication), and you are granted the necessary permissions (authorization). Many solutions have been proposed in the past, and the list keeps growing.
@@ -1402,7 +1401,7 @@ From simple to complex, here is my understanding of user identity management:
- By using OAuth 2.0, you can authorize one website to access your information on another website.
-### How to store passwords safely in the database and how to validate a password?
+### Ma'lumotlar bazasida parollarni qanday xavfsiz saqlash va parolni qanday tekshirish mumkin?
@@ -1435,7 +1434,7 @@ To validate a password, it can go through the following process:
1. The system appends the salt to the password and hashes it. Let’s call the hashed value H1.
1. The system compares H1 and H2, where H2 is the hash stored in the database. If they are the same, the password is valid.
-### Explaining JSON Web Token (JWT) to a 10 year old Kid
+### 10 yoshli bolaga JSON Web Token (JWT) haqida tushuntirish
@@ -1450,7 +1449,7 @@ Now, the signature is what makes the JWT secure. It's like a special seal that o
When you want to send the JWT to a server, you put the header, payload, and signature inside the box. Then you send it over to the server. The server can easily read the header and payload to understand who you are and what you want to do.
-### How does Google Authenticator (or other types of 2-factor authenticators) work?
+### Google Authenticator (yoki 2 faktorli autentifikatsiyaning boshqa turlari) qanday ishlaydi?
Google Authenticator is commonly used for logging into our accounts when 2-factor authentication is enabled. How does it guarantee security?
@@ -1494,9 +1493,9 @@ Is this authentication mechanism safe?
No. The password has 6 digits, so the generated password has 1 million potential combinations. Plus, the password changes every 30 seconds. If hackers want to guess the password in 30 seconds, they need to enter 30,000 combinations per second.
-## Real World Case Studies
+## Haqiqiy dunyo misollari
-### Netflix's Tech Stack
+### Netflixning Tech Stacki
This post is based on research from many Netflix engineering blogs and open-source projects. If you come across any inaccuracies, please feel free to inform us.
@@ -1520,7 +1519,7 @@ This post is based on research from many Netflix engineering blogs and open-sour
**CI/CD**: Netflix employs various tools such as JIRA, Confluence, PagerDuty, Jenkins, Gradle, Chaos Monkey, Spinnaker, Atlas, and more for CI/CD processes.
-### Twitter Architecture 2022
+### Twitter arxitekturasi 2022
Yes, this is the real Twitter architecture. It is posted by Elon Musk and redrawn by us for better readability.
@@ -1529,7 +1528,7 @@ Yes, this is the real Twitter architecture. It is posted by Elon Musk and redraw
-### Evolution of Airbnb’s microservice architecture over the past 15 years
+### Oxirgi 15 yil ichida Airbnb mikroservis arxitekturasining evolyutsiyasi
Airbnb’s microservice architecture went through 3 main stages.
@@ -1565,7 +1564,7 @@ Micro + macroservices (2020 - present)
This is what Airbnb is working on now. The micro and macroservice hybrid model focuses on the unification of APIs.
-### Monorepo vs. Microrepo.
+### Monorepo va mikrorepo.
Which is the best? Why do different companies choose different options?
@@ -1593,7 +1592,7 @@ Google engineers built Bazel, and Meta built Buck. There are other open-source t
Over the years, Microrepo has had more supported tools, including Maven and Gradle for Java, NPM for NodeJS, and CMake for C/C++, among others.
-### How will you design the Stack Overflow website?
+### Stack Overflow veb-saytini qanday loyihalashtirasiz?
If your answer is on-premise servers and monolith (on the bottom of the following image), you would likely fail the interview, but that's how it is built in reality!
@@ -1619,7 +1618,7 @@ Stack Overflow serves all the traffic with only 9 on-premise web servers, and it
This is contrary to all our popular beliefs these days.
-### Why did Amazon Prime Video monitoring move from serverless to monolithic? How can it save 90% cost?
+### Nima uchun Amazon Prime Video monitoringi serversizdan monolitga o'tdi? Qanday qilib 90% xarajatlarni tejash mumkin?
The diagram below shows the architecture comparison before and after the migration.
@@ -1654,7 +1653,7 @@ This is an interesting and unique case study because microservices have become a
Ex Amazon VP Sustainability Adrian Cockcroft: “The Prime Video team had followed a path I call **Serverless First**…I don’t advocate **Serverless Only**”.
-### How does Disney Hotstar capture 5 Billion Emojis during a tournament?
+### Disney Hotstar turnir davomida 5 milliard kulgichni qanday suratga oladi?
@@ -1675,7 +1674,7 @@ Ex Amazon VP Sustainability Adrian Cockcroft: “The Prime Video team had follow
A similar design is adopted by LinkedIn which streams a million likes/sec.
-### How Discord Stores Trillions Of Messages
+### Discord qanday qilib trillionlab xabarlarni saqlaydi?
The diagram below shows the evolution of message storage at Discord:
@@ -1702,7 +1701,7 @@ ScyllaDB is Cassandra compatible database written in C++. Discord redesigned its
The p99 read latency in ScyllaDB is 15ms compared to 40-125ms in Cassandra. The p99 write latency is 5ms compared to 5-70ms in Cassandra.
-### How do video live streamings work on YouTube, TikTok live, or Twitch?
+### YouTube, TikTok live yoki Twitch-da jonli video oqimlari qanday ishlaydi?
Live streaming differs from regular streaming because the video content is sent via the internet in real-time, usually with a latency of just a few seconds.
From ced6528a6d82ae210785a8cb37a9ded19947d028 Mon Sep 17 00:00:00 2001
From: realtemirov
Date: Fri, 24 Nov 2023 04:51:59 +0500
Subject: [PATCH 6/8] security
---
translations/README-uz.md | 425 +++++++++++++++++++-------------------
1 file changed, 213 insertions(+), 212 deletions(-)
diff --git a/translations/README-uz.md b/translations/README-uz.md
index 44857ce..6c00719 100644
--- a/translations/README-uz.md
+++ b/translations/README-uz.md
@@ -935,29 +935,29 @@ Nolinchi nusxa - dastur konteksti va yadro konteksti o'rtasida bir nechta ma'lum
### Nima uchun kredit karta "banklardagi eng daromadli mahsulot" deb ataladi? VISA/Mastercard qanday qilib pul ishlaydi?
-The diagram below shows the economics of the credit card payment flow.
+Quyidagi diagrammada kredit karta to'lovlari oqimining iqtisodiyoti ko'rsatilgan.
-1. The cardholder pays a merchant $100 to buy a product.
+1. Karta egasi mahsulot sotib olish uchun savdogarga 100 dollar to'laydi.
-2. The merchant benefits from the use of the credit card with higher sales volume and needs to compensate the issuer and the card network for providing the payment service. The acquiring bank sets a fee with the merchant, called the “merchant discount fee.”
+2. Savdogar yuqori savdo hajmiga ega kredit kartasidan foydalanishdan foyda oladi va to'lov xizmatini taqdim etganlik uchun emitent va karta tarmog'iga kompensatsiya to'lashi kerak. Qabul qiluvchi bank savdogardan "savdogar chegirma to'lovi" deb nomlangan to'lovni belgilaydi.
-3 - 4. The acquiring bank keeps $0.25 as the acquiring markup, and $1.75 is paid to the issuing bank as the interchange fee. The merchant discount fee should cover the interchange fee.
+3 - 4. Ekvaying bank ekvayring ustamasi sifatida 0,25 AQSh dollarini ushlab turadi va 1,75 AQSh dollari almashuv komissiyasi sifatida emitent bankka to'lanadi. Savdogar chegirma to'lovi almashinuv to'lovini qoplashi kerak.
- The interchange fee is set by the card network because it is less efficient for each issuing bank to negotiate fees with each merchant.
+O'zaro almashish to'lovi karta tarmog'i tomonidan belgilanadi, chunki har bir emitent bank uchun har bir savdogar bilan to'lovlarni kelishib olish unchalik samarali emas.
-5. The card network sets up the network assessments and fees with each bank, which pays the card network for its services every month. For example, VISA charges a 0.11% assessment, plus a $0.0195 usage fee, for every swipe.
+5. Karta tarmogʻi har bir bank bilan tarmoqni baholash va toʻlovlarni oʻrnatadi, u har oy karta tarmogʻiga oʻz xizmatlari uchun toʻlaydi. Masalan, VISA har bir surish uchun 0,11% baho va 0,0195 AQSh dollari miqdorida foydalanish to'lovini oladi.
-6. The cardholder pays the issuing bank for its services.
+6. Karta egasi emitent bankka xizmatlari uchun to'laydi.
-Why should the issuing bank be compensated?
+Nima uchun emitent bank kompensatsiya to'lashi kerak?
-- The issuer pays the merchant even if the cardholder fails to pay the issuer.
-- The issuer pays the merchant before the cardholder pays the issuer.
-- The issuer has other operating costs, including managing customer accounts, providing statements, fraud detection, risk management, clearing & settlement, etc.
+- Emitent karta egasi emitentga to'lamagan taqdirda ham savdogarga to'laydi.
+- Emitent karta egasi emitentga to'lashdan oldin savdogarga to'laydi.
+- Emitent boshqa operatsion xarajatlarga ega, jumladan, mijozlar hisoblarini boshqarish, hisobotlarni taqdim etish, firibgarlikni aniqlash, risklarni boshqarish, kliring va hisob-kitoblar va boshqalar.
### Savdogarlar do'konida kredit kartani o'tkazganimizda VISA qanday ishlaydi?
@@ -966,44 +966,44 @@ Why should the issuing bank be compensated?
-VISA, Mastercard, and American Express act as card networks for the clearing and settling of funds. The card acquiring bank and the card issuing bank can be – and often are – different. If banks were to settle transactions one by one without an intermediary, each bank would have to settle the transactions with all the other banks. This is quite inefficient.
+VISA, Mastercard va American Express pul mablag'larini kliring va hisob-kitob qilish uchun karta tarmoqlari sifatida ishlaydi. Kartani qabul qiluvchi bank va kartani emitent banki har xil bo'lishi mumkin va ko'pincha bir-biridan farq qiladi. Agar banklar birin-ketin hisob-kitoblarni vositachisiz amalga oshirsalar, har bir bank boshqa barcha banklar bilan hisob-kitob qilishlari kerak edi. Bu juda samarasiz.
-The diagram below shows VISA’s role in the credit card payment process. There are two flows involved. Authorization flow happens when the customer swipes the credit card. Capture and settlement flow happens when the merchant wants to get the money at the end of the day.
+Quyidagi diagrammada VISA ning kredit karta bilan to'lov jarayonidagi roli ko'rsatilgan. Ikkita oqim ishtirok etadi. Avtorizatsiya oqimi mijoz kredit kartasini surish paytida sodir bo'ladi. Qo'lga olish va hisob-kitoblar oqimi savdogar kunning oxirida pul olishni xohlasa sodir bo'ladi.
-- Authorization Flow
+- Avtorizatsiya oqimi
-Step 0: The card issuing bank issues credit cards to its customers.
+0-qadam: Kartani chiqaruvchi bank o'z mijozlariga kredit kartalarini chiqaradi.
-Step 1: The cardholder wants to buy a product and swipes the credit card at the Point of Sale (POS) terminal in the merchant’s shop.
+1-qadam: Karta egasi mahsulot sotib olmoqchi va kredit kartani sotuvchining do'konidagi Savdo nuqtasi (POS) terminalida suradi.
-Step 2: The POS terminal sends the transaction to the acquiring bank, which has provided the POS terminal.
+2-qadam: POS-terminal tranzaktsiyani POS-terminalni taqdim etgan ekvaying bankka yuboradi.
-Steps 3 and 4: The acquiring bank sends the transaction to the card network, also called the card scheme. The card network sends the transaction to the issuing bank for approval.
+3 va 4-qadamlar: Ekvaying bank tranzaktsiyani kartalar tarmog'iga yuboradi, shuningdek, karta sxemasi deb ataladi. Karta tarmog'i tranzaksiyani tasdiqlash uchun emitent bankka yuboradi.
-Steps 4.1, 4.2 and 4.3: The issuing bank freezes the money if the transaction is approved. The approval or rejection is sent back to the acquirer, as well as the POS terminal.
+4.1, 4.2 va 4.3-qadamlar: Agar tranzaktsiya tasdiqlangan bo'lsa, emitent bank pulni muzlatib qo'yadi. Tasdiqlash yoki rad etish ekvayerga, shuningdek POS terminalga qaytariladi.
-- Capture and Settlement Flow
+- Qo'lga olish va joylashtirish oqimi
-Steps 1 and 2: The merchant wants to collect the money at the end of the day, so they hit ”capture” on the POS terminal. The transactions are sent to the acquirer in batch. The acquirer sends the batch file with transactions to the card network.
+1 va 2-qadamlar: Savdogar kun oxirida pul yig'ishni xohlaydi, shuning uchun ular POS terminalida "qo'lga olish" tugmasini bosadilar. Tranzaktsiyalar to'plamda ekvayerga yuboriladi. Ekvayer paketli faylni tranzaktsiyalar bilan karta tarmog'iga yuboradi.
-Step 3: The card network performs clearing for the transactions collected from different acquirers, and sends the clearing files to different issuing banks.
+3-qadam: Karta tarmog'i turli ekvayerlardan yig'ilgan tranzaktsiyalar uchun kliringni amalga oshiradi va kliring fayllarini turli emitent banklarga yuboradi.
-Step 4: The issuing banks confirm the correctness of the clearing files, and transfer money to the relevant acquiring banks.
+4-qadam: Emitent banklar kliring fayllari to'g'riligini tasdiqlaydi va tegishli ekvayring banklarga pul o'tkazadi.
-Step 5: The acquiring bank then transfers money to the merchant’s bank.
+5-qadam: Ekvayer bank so'ng savdogarning bankiga pul o'tkazadi.
-Step 4: The card network clears up the transactions from different acquiring banks. Clearing is a process in which mutual offset transactions are netted, so the number of total transactions is reduced.
+6-qadam: Karta tarmog'i turli ekvayring banklardan tranzaktsiyalarni tozalaydi. Kliring - bu o'zaro kompensatsiya operatsiyalari hisoblangan jarayondir, shuning uchun umumiy operatsiyalar soni kamayadi.
-In the process, the card network takes on the burden of talking to each bank and receives service fees in return.
+Bu jarayonda karta tarmog'i har bir bank bilan gaplashish yukini o'z zimmasiga oladi va buning evaziga xizmat haqi oladi.
### Dunyo bo'ylab to'lov tizimlari seriyasi (1-qism): Hindistonda yagona to'lov interfeysi (UPI)
-What’s UPI? UPI is an instant real-time payment system developed by the National Payments Corporation of India.
+UPI nima? UPI - bu Hindiston Milliy To'lovlar Korporatsiyasi tomonidan ishlab chiqilgan tezkor real vaqtda to'lov tizimi.
-It accounts for 60% of digital retail transactions in India today.
+Bugungi kunda Hindistondagi raqamli chakana savdo operatsiyalarining 60% ni tashkil qiladi.
-UPI = payment markup language + standard for interoperable payments
+UPI = to'lovni belgilash tili + o'zaro to'lovlar uchun standart
@@ -1015,63 +1015,63 @@ UPI = payment markup language + standard for interoperable payments
### DevOps va SRE va platforma muhandisligi. Farqi nimada?
-The concepts of DevOps, SRE, and Platform Engineering have emerged at different times and have been developed by various individuals and organizations.
+DevOps, SRE va Platform Engineering kontseptsiyalari turli vaqtlarda paydo bo'lgan va turli shaxslar va tashkilotlar tomonidan ishlab chiqilgan.
-DevOps as a concept was introduced in 2009 by Patrick Debois and Andrew Shafer at the Agile conference. They sought to bridge the gap between software development and operations by promoting a collaborative culture and shared responsibility for the entire software development lifecycle.
+DevOps kontseptsiya sifatida 2009 yilda Agile konferentsiyasida Patrik Debois va Endryu Shafer tomonidan taqdim etilgan. Ular hamkorlik madaniyatini va dasturiy ta'minotni ishlab chiqishning butun hayotiy tsikli uchun umumiy mas'uliyatni rag'batlantirish orqali dasturiy ta'minotni ishlab chiqish va operatsiyalar o'rtasidagi tafovutni bartaraf etishga intildi.
-SRE, or Site Reliability Engineering, was pioneered by Google in the early 2000s to address operational challenges in managing large-scale, complex systems. Google developed SRE practices and tools, such as the Borg cluster management system and the Monarch monitoring system, to improve the reliability and efficiency of their services.
+SRE yoki Site Reliability Engineering 2000-yillarning boshida Google tomonidan keng koʻlamli, murakkab tizimlarni boshqarishdagi operatsion muammolarni hal qilish uchun kashshof boʻlgan. Google xizmatlarining ishonchliligi va samaradorligini oshirish uchun Borg klasterini boshqarish tizimi va Monarch monitoring tizimi kabi SRE amaliyotlari va vositalarini ishlab chiqdi.
-Platform Engineering is a more recent concept, building on the foundation of SRE engineering. The precise origins of Platform Engineering are less clear, but it is generally understood to be an extension of the DevOps and SRE practices, with a focus on delivering a comprehensive platform for product development that supports the entire business perspective.
+Platforma muhandisligi - bu SRE muhandisligi asosiga qurilgan eng yangi kontseptsiya. Platforma muhandisligining aniq kelib chiqishi unchalik aniq emas, lekin bu odatda DevOps va SRE amaliyotlarining kengaytmasi sifatida tushuniladi, asosiy e'tibor butun biznes istiqbolini qo'llab-quvvatlaydigan mahsulotni ishlab chiqish uchun keng qamrovli platformani taqdim etishga qaratilgan.
-It's worth noting that while these concepts emerged at different times. They are all related to the broader trend of improving collaboration, automation, and efficiency in software development and operations.
+Ta'kidlash joizki, bu tushunchalar turli davrlarda paydo bo'lgan. Ularning barchasi dasturiy ta'minotni ishlab chiqish va ishlashda hamkorlik, avtomatlashtirish va samaradorlikni oshirishning kengroq tendentsiyasi bilan bog'liq.
### K8s (Kubernetes) nima?
-K8s is a container orchestration system. It is used for container deployment and management. Its design is greatly impacted by Google’s internal system Borg.
+K8s konteyner orkestrlash tizimidir. U konteynerni joylashtirish va boshqarish uchun ishlatiladi. Uning dizayniga Google ichki tizimi Borg katta ta'sir ko'rsatadi.
-A k8s cluster consists of a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node.
+K8s klasteri konteynerlashtirilgan ilovalarni ishga tushiradigan tugunlar deb ataladigan ishchi mashinalar to'plamidan iborat. Har bir klasterda kamida bitta ishchi tugun mavjud.
-The worker node(s) host the Pods that are the components of the application workload. The control plane manages the worker nodes and the Pods in the cluster. In production environments, the control plane usually runs across multiple computers, and a cluster usually runs multiple nodes, providing fault tolerance and high availability.
+Ishchi tugun(lar) dastur ish yukining komponentlari bo'lgan podlarni joylashtiradi. Boshqaruv tekisligi ishchi tugunlarni va klasterdagi podlarni boshqaradi. Ishlab chiqarish muhitida boshqaruv tekisligi odatda bir nechta kompyuterlar bo'ylab ishlaydi va klaster odatda xatolarga chidamlilik va yuqori mavjudlikni ta'minlaydigan bir nechta tugunlarni boshqaradi.
-- Control Plane Components
+- Tekshirish tekisligi komponentlari
-1. API Server
+1. API serveri
- The API server talks to all the components in the k8s cluster. All the operations on pods are executed by talking to the API server.
+ API serveri k8s klasteridagi barcha komponentlar bilan gaplashadi. Podkalardagi barcha operatsiyalar API serveri bilan gaplashish orqali amalga oshiriladi.
-2. Scheduler
+2. Rejalashtiruvchi
- The scheduler watches pod workloads and assigns loads on newly created pods.
+ Rejalashtiruvchi pod ish yuklarini kuzatadi va yangi yaratilgan podkalarga yuklarni tayinlaydi.
-3. Controller Manager
+3. Nazoratchi menejeri
- The controller manager runs the controllers, including Node Controller, Job Controller, EndpointSlice Controller, and ServiceAccount Controller.
+ Nazoratchi menejeri kontrollerlarni, jumladan Node Controller, Job Controller, EndpointSlice Controller va ServiceAccount Controllerni boshqaradi.
4. Etcd
- etcd is a key-value store used as Kubernetes' backing store for all cluster data.
+ etcd - barcha klaster ma'lumotlari uchun Kubernetesning qo'llab-quvvatlovchi do'koni sifatida foydalaniladigan kalit-qiymat do'koni.
-- Nodes
+- Tugunlar
-1. Pods
+1. Podlar
- A pod is a group of containers and is the smallest unit that k8s administers. Pods have a single IP address applied to every container within the pod.
+ Pod - bu konteynerlar guruhi va k8s boshqaradigan eng kichik birlikdir. Podlar pod ichidagi har bir konteynerga qo'llaniladigan yagona IP-manzilga ega.
2. Kubelet
- An agent that runs on each node in the cluster. It ensures containers are running in a Pod.
+ Klasterdagi har bir tugunda ishlaydigan agent. Bu konteynerlarning Podda ishlashini ta'minlaydi.
-3. Kube Proxy
+3. Kube proksi
- Kube-proxy is a network proxy that runs on each node in your cluster. It routes traffic coming into a node from the service. It forwards requests for work to the correct containers.
+ Kube-proksi - bu klasteringizdagi har bir tugunda ishlaydigan tarmoq proksi-serveri. U xizmatdan tugunga keladigan trafikni yo'naltiradi. U ish uchun so'rovlarni to'g'ri konteynerlarga yuboradi.
### Docker va Kubernetes. Qaysi birini ishlatishimiz kerak?
@@ -1080,118 +1080,117 @@ The worker node(s) host the Pods that are the components of the application work
-What is Docker ?
+Docker nima?
-Docker is an open-source platform that allows you to package, distribute, and run applications in isolated containers. It focuses on containerization, providing lightweight environments that encapsulate applications and their dependencies.
+Docker ochiq kodli platforma bo'lib, u alohida konteynerlarda ilovalarni paketlash, tarqatish va ishga tushirish imkonini beradi. U konteynerlashtirishga qaratilgan bo'lib, ilovalar va ularning bog'liqliklarini qamrab oladigan engil muhitlarni ta'minlaydi.
-What is Kubernetes ?
+Kubernetes nima?
-Kubernetes, often referred to as K8s, is an open-source container orchestration platform. It provides a framework for automating the deployment, scaling, and management of containerized applications across a cluster of nodes.
+Ko'pincha K8s deb ataladigan Kubernetes ochiq manbali konteyner orkestr platformasidir. U tugunlar klasterida konteynerlashtirilgan ilovalarni joylashtirish, masshtablash va boshqarishni avtomatlashtirish uchun asos yaratadi.
-How are both different from each other ?
+Ikkalasi bir-biridan qanday farq qiladi?
-Docker: Docker operates at the individual container level on a single operating system host.
+Docker: Docker bitta operatsion tizim xostida individual konteyner darajasida ishlaydi.
-You must manually manage each host and setting up networks, security policies, and storage for multiple related containers can be complex.
+Har bir xostni qo'lda boshqarishingiz kerak va tarmoqlarni sozlash, xavfsizlik siyosati va bir nechta tegishli konteynerlar uchun saqlash murakkab bo'lishi mumkin.
-Kubernetes: Kubernetes operates at the cluster level. It manages multiple containerized applications across multiple hosts, providing automation for tasks like load balancing, scaling, and ensuring the desired state of applications.
+Kubernetes: Kubernetes klaster darajasida ishlaydi. U bir nechta hostlarda bir nechta konteynerli ilovalarni boshqaradi, yuklarni muvozanatlash, masshtablash va ilovalarning kerakli holatini ta'minlash kabi vazifalarni avtomatlashtirishni ta'minlaydi.
-In short, Docker focuses on containerization and running containers on individual hosts, while Kubernetes specializes in managing and orchestrating containers at scale across a cluster of hosts.
+Muxtasar qilib aytganda, Docker alohida xostlarda konteynerlashtirish va konteynerlarni ishga tushirishga e'tibor qaratadi, Kubernetes esa xostlar klasteri bo'ylab konteynerlarni boshqarish va tartibga solishga ixtisoslashgan.
### Docker qanday ishlaydi?
-The diagram below shows the architecture of Docker and how it works when we run “docker build”, “docker pull”
-and “docker run”.
+Quyidagi diagrammada Docker arxitekturasi va biz "docker build", "docker pull" va "docker run" ni ishga tushirganimizda qanday ishlashi ko'rsatilgan.
-There are 3 components in Docker architecture:
+Docker arxitekturasida 3 ta komponent mavjud:
-- Docker client
+- Docker mijozi
- The docker client talks to the Docker daemon.
+ Docker mijozi Docker demoni bilan gaplashadi.
- Docker host
- The Docker daemon listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes.
+ Docker demoni Docker API so‘rovlarini tinglaydi va tasvirlar, konteynerlar, tarmoqlar va hajmlar kabi Docker obyektlarini boshqaradi.
-- Docker registry
+- Docker registrlari
- A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use.
+ Docker registrida Docker tasvirlari saqlanadi. Docker Hub - bu hamma foydalanishi mumkin bo'lgan ommaviy reestr.
-Let’s take the “docker run” command as an example.
+Misol sifatida "docker run" buyrug'ini olaylik.
- 1. Docker pulls the image from the registry.
- 1. Docker creates a new container.
- 1. Docker allocates a read-write filesystem to the container.
- 1. Docker creates a network interface to connect the container to the default network.
- 1. Docker starts the container.
+ 1. Docker tasvirni registrdan oladi.
+ 2. Docker yangi konteyner yaratadi.
+ 3. Docker konteynerga o'qish va yozish fayl tizimini ajratadi.
+ 4. Docker konteynerni standart tarmoqqa ulash uchun tarmoq interfeysini yaratadi.
+ 5. Docker konteynerni ishga tushiradi.
## GIT
### Git buyruqlari qanday ishlaydi
-To begin with, it's essential to identify where our code is stored. The common assumption is that there are only two locations - one on a remote server like Github and the other on our local machine. However, this isn't entirely accurate. Git maintains three local storages on our machine, which means that our code can be found in four places:
+Boshlash uchun kodimiz qayerda saqlanishini aniqlash kerak. Umumiy taxmin shundan iboratki, faqat ikkita joy bor - biri Github kabi uzoq serverda, ikkinchisi bizning mahalliy mashinamizda. Biroq, bu to'liq aniq emas. Git bizning mashinamizda uchta mahalliy xotirani saqlaydi, ya'ni bizning kodimizni to'rtta joyda topish mumkin:
-- Working directory: where we edit files
-- Staging area: a temporary location where files are kept for the next commit
-- Local repository: contains the code that has been committed
-- Remote repository: the remote server that stores the code
+- Ishchi katalog: biz fayllarni tahrir qiladigan joy
+- Sahna maydoni: fayllar keyingi topshiriq uchun saqlanadigan vaqtinchalik joy
+- Mahalliy ombor: o'rnatilgan kodni o'z ichiga oladi
+- Masofaviy ombor: kodni saqlaydigan masofaviy server
-Most Git commands primarily move files between these four locations.
+Ko'pgina Git buyruqlari asosan fayllarni ushbu to'rtta joy o'rtasida ko'chiradi.
### Git qanday ishlaydi?
-The diagram below shows the Git workflow.
+Quyidagi diagrammada Git ish jarayoni ko'rsatilgan.
-Git is a distributed version control system.
+Git - bu taqsimlangan versiyani boshqarish tizimi.
-Every developer maintains a local copy of the main repository and edits and commits to the local copy.
+Har bir ishlab chiquvchi asosiy omborning mahalliy nusxasini saqlaydi va mahalliy nusxani tahrirlaydi va majburiyatini oladi.
-The commit is very fast because the operation doesn’t interact with the remote repository.
+Amal qilish juda tez, chunki operatsiya masofaviy ombor bilan o'zaro ta'sir qilmaydi.
-If the remote repository crashes, the files can be recovered from the local repositories.
+Agar masofaviy ombor ishlamay qolsa, fayllar mahalliy omborlardan tiklanishi mumkin.
-### Git merge va Git rebase]
+### Git merge va Git rebase
-What are the differences?
+Qanday farqlar bor?
-When we **merge changes** from one Git branch to another, we can use ‘git merge’ or ‘git rebase’. The diagram below shows how the two commands work.
+**O'zgarishlar**ni bir Git filialidan boshqasiga **birlashtirgan**da, biz "git merge" yoki "git rebase" dan foydalanishimiz mumkin. Quyidagi diagrammada ikkita buyruq qanday ishlashi ko'rsatilgan.
**Git merge**
-This creates a new commit G’ in the main branch. G’ ties the histories of both main and feature branches.
+Bu asosiy filialda yangi G' majburiyatini yaratadi. G' asosiy va xususiyatli tarmoqlarning tarixini bog'laydi.
-Git merge is **non-destructive**. Neither the main nor the feature branch is changed.
+Git birlashmasi **buzilmaydi**. Na asosiy, na xususiyat filiali o'zgartirilmaydi.
-**Git rebase**
+**Git birlashmasi (Git rebase)**
-Git rebase moves the feature branch histories to the head of the main branch. It creates new commits E’, F’, and G’ for each commit in the feature branch.
+Git rebase xususiyat filiallari tarixini asosiy filialning boshiga o'tkazadi. U xususiyat bo'limidagi har bir topshiriq uchun yangi E', F' va G' majburiyatlarini yaratadi.
-The benefit of rebase is that it has a linear **commit history**.
+Qayta tiklashning afzalligi shundaki, u chiziqli **majburiyat tarixiga (commit history)** ega.
-Rebase can be dangerous if “the golden rule of git rebase” is not followed.
+Agar "git rebase ning oltin qoidasiga" rioya qilinmasa, rebase xavfli bo'lishi mumkin.
-**The Golden Rule of Git Rebase**
+**Git Rebase ning oltin qoidasi (The Golden Rule of Git Rebase)**
-Never use it on public branches!
+Uni hech qachon ommaviy filiallarida ishlatmang!
## Bulutli xizmatlar
@@ -1204,43 +1203,43 @@ Never use it on public branches!
### Mahalliy bulut nima?
-Below is a diagram showing the evolution of architecture and processes since the 1980s.
+Quyida 1980-yillardan beri arxitektura va jarayonlarning evolyutsiyasini ko'rsatadigan diagramma keltirilgan.
-Organizations can build and run scalable applications on public, private, and hybrid clouds using cloud native technologies.
+Tashkilotlar bulutli mahalliy texnologiyalardan foydalangan holda ommaviy, xususiy va gibrid bulutlarda kengaytiriladigan ilovalarni yaratishi va ishga tushirishi mumkin.
-This means the applications are designed to leverage cloud features, so they are resilient to load and easy to scale.
+Bu shuni anglatadiki, ilovalar bulut xususiyatlaridan foydalanish uchun mo'ljallangan, shuning uchun ular yuklanishga chidamli va masshtablash oson.
-Cloud native includes 4 aspects:
+Cloud native 4 jihatni o'z ichiga oladi:
-1. Development process
+1. Rivojlanish jarayoni
- This has progressed from waterfall to agile to DevOps.
+ Bu sharsharadan agilegacha, DevOpsga o'tdi.
-2. Application Architecture
+2. Ilova arxitekturasi
- The architecture has gone from monolithic to microservices. Each service is designed to be small, adaptive to the limited resources in cloud containers.
+ Arxitektura monolitlikdan mikroservislarga o'tdi. Har bir xizmat kichik, bulutli konteynerlardagi cheklangan resurslarga moslashish uchun mo'ljallangan.
-3. Deployment & packaging
+3. Joylashtirish va qadoqlash
- The applications used to be deployed on physical servers. Then around 2000, the applications that were not sensitive to latency were usually deployed on virtual servers. With cloud native applications, they are packaged into docker images and deployed in containers.
+ Ilovalar jismoniy serverlarda o'rnatilar edi. Keyin 2000-yillarda kechikishga sezgir bo'lmagan ilovalar odatda virtual serverlarda o'rnatildi. Bulutli mahalliy ilovalar bilan ular docker tasvirlariga o'raladi va konteynerlarga joylashtiriladi.
-4. Application infrastructure
+4. Ilova infratuzilmasi
- The applications are massively deployed on cloud infrastructure instead of self-hosted servers.
+ Ilovalar o'z-o'zidan joylashtirilgan serverlar o'rniga bulutli infratuzilmada ommaviy ravishda joylashtirilgan.
## Ishlab chiquvchi mahsuldorlik vositalari
### JSON fayllarini vizualizatsiya qilish
-Nested JSON files are hard to read.
+Ichki JSON fayllarini o'qish qiyin.
-**JsonCrack** generates graph diagrams from JSON files and makes them easy to read.
+**JsonCrack** JSON fayllaridan grafik diagrammalarni yaratadi va ularni o'qishni osonlashtiradi.
-Additionally, the generated diagrams can be downloaded as images.
+Bundan tashqari, yaratilgan diagrammalarni tasvir sifatida yuklab olish mumkin.
@@ -1254,12 +1253,12 @@ Additionally, the generated diagrams can be downloaded as images.
-What does it do?
+Bu nima qiladi?
-- Draw the cloud system architecture in Python code.
-- Diagrams can also be rendered directly inside the Jupyter Notebooks.
-- No design tools are needed.
-- Supports the following providers: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud, etc.
+- Python kodida bulut tizimi arxitekturasini chizing.
+- Diagrammalar to'g'ridan-to'g'ri Jupyter noutbuklarida ham ko'rsatilishi mumkin.
+- Dizayn vositalari kerak emas.
+- Quyidagi provayderlarni qo'llab-quvvatlaydi: AWS, Azure, GCP, Kubernetes, Alibaba Cloud, Oracle Cloud va boshqalar.
[Github repo](https://github.com/mingrammer/diagrams)
@@ -1271,91 +1270,90 @@ What does it do?
-The Linux file system used to resemble an unorganized town where individuals constructed their houses wherever they pleased. However, in 1994, the Filesystem Hierarchy Standard (FHS) was introduced to bring order to the Linux file system.
+Linux fayl tizimi uyushmagan shaharchaga o'xshar edi, u erda odamlar o'z uylarini xohlagan joyda quradilar. Biroq, 1994 yilda Linux fayl tizimini tartibga solish uchun Fayl tizimi ierarxiyasi standarti (FHS) joriy etildi.
-By implementing a standard like the FHS, software can ensure a consistent layout across various Linux distributions. Nonetheless, not all Linux distributions strictly adhere to this standard. They often incorporate their own unique elements or cater to specific requirements.
-To become proficient in this standard, you can begin by exploring. Utilize commands such as "cd" for navigation and "ls" for listing directory contents. Imagine the file system as a tree, starting from the root (/). With time, it will become second nature to you, transforming you into a skilled Linux administrator.
+FHS kabi standartni amalga oshirish orqali dasturiy ta'minot turli xil Linux distributivlarida izchil tartibni ta'minlashi mumkin. Shunga qaramay, barcha Linux distributivlari ushbu standartga qat'iy rioya qilmaydi. Ular ko'pincha o'zlarining noyob elementlarini o'z ichiga oladi yoki muayyan talablarga javob beradi. Ushbu standartda malakali bo'lish uchun siz kashf qilishdan boshlashingiz mumkin. Navigatsiya uchun "cd" va katalog tarkibini ro'yxatga olish uchun "ls" kabi buyruqlardan foydalaning. Fayl tizimini ildiz (/) dan boshlab daraxt sifatida tasavvur qiling. Vaqt o'tishi bilan u siz uchun ikkinchi tabiatga aylanadi va sizni malakali Linux ma'muriga aylantiradi.
### Siz bilishingiz kerak bo'lgan 18 ta eng ko'p ishlatiladigan Linux buyruqlari
-Linux commands are instructions for interacting with the operating system. They help manage files, directories, system processes, and many other aspects of the system. You need to become familiar with these commands in order to navigate and maintain Linux-based systems efficiently and effectively.
+Linux buyruqlari operatsion tizim bilan o'zaro ishlash uchun ko'rsatmalardir. Ular fayllarni, kataloglarni, tizim jarayonlarini va tizimning boshqa ko'plab jihatlarini boshqarishga yordam beradi. Linux-ga asoslangan tizimlarni samarali va samarali boshqarish uchun siz ushbu buyruqlar bilan tanishishingiz kerak.
-This diagram below shows popular Linux commands:
+Quyidagi diagrammada mashhur Linux buyruqlari ko'rsatilgan:
-- ls - List files and directories
-- cd - Change the current directory
-- mkdir - Create a new directory
-- rm - Remove files or directories
-- cp - Copy files or directories
-- mv - Move or rename files or directories
-- chmod - Change file or directory permissions
-- grep - Search for a pattern in files
-- find - Search for files and directories
-- tar - manipulate tarball archive files
-- vi - Edit files using text editors
-- cat - display the content of files
-- top - Display processes and resource usage
-- ps - Display processes information
-- kill - Terminate a process by sending a signal
-- du - Estimate file space usage
-- ifconfig - Configure network interfaces
-- ping - Test network connectivity between hosts
+- ls - Fayllar va kataloglarni ro'yxatlash
+- cd - Joriy katalogni o'zgartirish
+- mkdir - Yangi katalog yarating
+- rm - Fayllar yoki kataloglarni olib tashlang
+- cp - fayllar yoki kataloglarni nusxalash
+- mv - fayllar yoki kataloglarni ko'chirish yoki nomini o'zgartirish
+- chmod - fayl yoki katalog ruxsatlarini o'zgartirish
+- grep - fayllardan naqsh izlash
+- find - fayllar va kataloglarni qidirish
+- tar - tarball arxiv fayllarini boshqarish
+- vi - matn muharrirlari yordamida fayllarni tahrirlash
+- cat - fayllar tarkibini ko'rsatish
+- top - jarayonlar va resurslardan foydalanishni ko'rsatish
+- ps - displey ma'lumotlarni qayta ishlaydi
+- kill - signal yuborish orqali jarayonni tugatish
+- du - fayl maydonidan foydalanishni taxmin qilish
+- ifconfig - Tarmoq interfeyslarini sozlang
+- ping - Xostlar o'rtasida tarmoq ulanishini sinab ko'ring
## Xavfsizlik
### HTTPS qanday ishlaydi?
-Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP.) HTTPS transmits encrypted data using Transport Layer Security (TLS.) If the data is hijacked online, all the hijacker gets is binary code.
+Xavfsiz gipermatn uzatish protokoli (HTTPS) gipermatnni uzatish protokolining (HTTP) kengaytmasi bo'lib, HTTPS shifrlangan ma'lumotlarni Transport Layer Security (TLS) yordamida uzatadi.
-How is the data encrypted and decrypted?
+Ma'lumotlar qanday shifrlangan va shifrlangan?
-Step 1 - The client (browser) and the server establish a TCP connection.
+1-qadam - mijoz (brauzer) va server TCP ulanishini o'rnatadi.
-Step 2 - The client sends a “client hello” to the server. The message contains a set of necessary encryption algorithms (cipher suites) and the latest TLS version it can support. The server responds with a “server hello” so the browser knows whether it can support the algorithms and TLS version.
+2-qadam - Mijoz serverga "mijozga salom" yuboradi. Xabarda zarur shifrlash algoritmlari toʻplami (shifr toʻplami) va u qoʻllab-quvvatlaydigan soʻnggi TLS versiyasi mavjud. Server "serverga salom" bilan javob beradi, shuning uchun brauzer algoritmlar va TLS versiyasini qo'llab-quvvatlashi mumkinligini biladi.
-The server then sends the SSL certificate to the client. The certificate contains the public key, host name, expiry dates, etc. The client validates the certificate.
+Keyin server mijozga SSL sertifikatini yuboradi. Sertifikatda ochiq kalit, xost nomi, amal qilish muddati va boshqalar mavjud. Mijoz sertifikatni tasdiqlaydi.
-Step 3 - After validating the SSL certificate, the client generates a session key and encrypts it using the public key. The server receives the encrypted session key and decrypts it with the private key.
+3-qadam - SSL sertifikatini tekshirgandan so'ng, mijoz sessiya kalitini yaratadi va uni ochiq kalit yordamida shifrlaydi. Server shifrlangan seans kalitini oladi va uni shaxsiy kalit bilan hal qiladi.
-Step 4 - Now that both the client and the server hold the same session key (symmetric encryption), the encrypted data is transmitted in a secure bi-directional channel.
+4-qadam -- Endi mijoz ham, server ham bir xil seans kalitiga ega (simmetrik shifrlash), shifrlangan maʼlumotlar xavfsiz ikki yoʻnalishli kanalda uzatiladi.
-Why does HTTPS switch to symmetric encryption during data transmission? There are two main reasons:
+Nima uchun HTTPS ma'lumotlarni uzatishda nosimmetrik shifrlashga o'tadi? Ikkita asosiy sabab bor:
-1. Security: The asymmetric encryption goes only one way. This means that if the server tries to send the encrypted data back to the client, anyone can decrypt the data using the public key.
+1. Xavfsizlik: assimetrik shifrlash faqat bitta yo'l bilan amalga oshiriladi. Bu shuni anglatadiki, agar server shifrlangan ma'lumotlarni mijozga qaytarib yuborishga harakat qilsa, har kim ochiq kalit yordamida ma'lumotlarning shifrini ochishi mumkin.
-2. Server resources: The asymmetric encryption adds quite a lot of mathematical overhead. It is not suitable for data transmissions in long sessions.
+2. Server resurslari: assimetrik shifrlash juda ko'p matematik yuklarni qo'shadi. Uzoq seanslarda ma'lumotlarni uzatish uchun mos emas.
### Oauth 2.0 oddiy shartlar bilan tushuntirilgan.
-OAuth 2.0 is a powerful and secure framework that allows different applications to securely interact with each other on behalf of users without sharing sensitive credentials.
+OAuth 2.0 kuchli va xavfsiz tizim boʻlib, u turli ilovalarga maxfiy hisob maʼlumotlarini baham koʻrmasdan foydalanuvchilar nomidan bir-biri bilan xavfsiz oʻzaro aloqada boʻlish imkonini beradi.
-The entities involved in OAuth are the User, the Server, and the Identity Provider (IDP).
+OAuth bilan bog'liq bo'lgan ob'ektlar - bu foydalanuvchi, server va identifikatsiya provayderi (IDP).
-What Can an OAuth Token Do?
+OAuth tokeni nima qila oladi?
-When you use OAuth, you get an OAuth token that represents your identity and permissions. This token can do a few important things:
+OAuth-dan foydalanganda siz shaxsingiz va ruxsatlaringizni ifodalovchi OAuth tokenini olasiz. Ushbu token bir nechta muhim ishlarni bajarishi mumkin:
-Single Sign-On (SSO): With an OAuth token, you can log into multiple services or apps using just one login, making life easier and safer.
+Yagona tizimga kirish (SSO): OAuth tokeni yordamida siz faqat bitta login yordamida bir nechta xizmatlar yoki ilovalarga kirishingiz mumkin, bu esa hayotni oson va xavfsizroq qiladi.
-Authorization Across Systems: The OAuth token allows you to share your authorization or access rights across various systems, so you don't have to log in separately everywhere.
+Tizimlar bo'ylab avtorizatsiya: OAuth tokeni avtorizatsiya yoki kirish huquqlarini turli tizimlar bo'ylab almashish imkonini beradi, shuning uchun hamma joyda alohida tizimga kirishingiz shart emas.
-Accessing User Profile: Apps with an OAuth token can access certain parts of your user profile that you allow, but they won't see everything.
+Foydalanuvchi profiliga kirish: OAuth tokeni boʻlgan ilovalar siz ruxsat bergan foydalanuvchi profilingizning ayrim qismlariga kirishi mumkin, lekin ular hammasini koʻra olmaydi.
-Remember, OAuth 2.0 is all about keeping you and your data safe while making your online experiences seamless and hassle-free across different applications and services.
+Esingizda bo'lsin, OAuth 2.0 barcha ilovalar va xizmatlarda onlayn tajribangizni muammosiz va muammosiz qilish bilan birga sizni va ma'lumotlaringizni xavfsiz saqlashga qaratilgan.
### Autentifikatsiya mexanizmlarining 4 ta eng yaxshi shakllari
@@ -1363,43 +1361,43 @@ Remember, OAuth 2.0 is all about keeping you and your data safe while making you
-1. SSH Keys:
+1. SSH kalitlari:
- Cryptographic keys are used to access remote systems and servers securely
+ Kriptografik kalitlar masofaviy tizimlar va serverlarga xavfsiz kirish uchun ishlatiladi
-1. OAuth Tokens:
+1. OAuth tokenlari:
- Tokens that provide limited access to user data on third-party applications
+ Uchinchi tomon ilovalarida foydalanuvchi ma'lumotlariga cheklangan kirishni ta'minlaydigan tokenlar
-1. SSL Certificates:
+1. SSL sertifikatlari:
- Digital certificates ensure secure and encrypted communication between servers and clients
+ Raqamli sertifikatlar serverlar va mijozlar o'rtasida xavfsiz va shifrlangan aloqani ta'minlaydi
-1. Credentials:
+1. Hisob maʼlumotlari::
- User authentication information is used to verify and grant access to various systems and services
+ Foydalanuvchi autentifikatsiya ma'lumotlari turli tizimlar va xizmatlarga kirishni tekshirish va ruxsat berish uchun ishlatiladi
### Sessiya, cookie, JWT, token, SSO va OAuth 2.0 - ular nima?
-These terms are all related to user identity management. When you log into a website, you declare who you are (identification). Your identity is verified (authentication), and you are granted the necessary permissions (authorization). Many solutions have been proposed in the past, and the list keeps growing.
+Ushbu shartlarning barchasi foydalanuvchi identifikatorini boshqarish bilan bog'liq. Veb-saytga kirganingizda, siz kimligingizni e'lon qilasiz (identifikatsiya). Shaxsingiz tasdiqlandi (autentifikatsiya) va sizga kerakli ruxsatnomalar (avtorizatsiya) beriladi. O'tmishda ko'plab echimlar taklif qilingan va ro'yxat o'sib bormoqda.
-From simple to complex, here is my understanding of user identity management:
+Oddiydan murakkabgacha, men foydalanuvchi identifikatorini boshqarish haqidagi tushuncham:
-- WWW-Authenticate is the most basic method. You are asked for the username and password by the browser. As a result of the inability to control the login life cycle, it is seldom used today.
+- WWW-Authenticate - eng asosiy usul. Brauzer sizdan foydalanuvchi nomi va parolni so'raydi. Loginning hayot aylanishini nazorat qila olmaslik natijasida bugungi kunda u kamdan-kam qo'llaniladi.
-- A finer control over the login life cycle is session-cookie. The server maintains session storage, and the browser keeps the ID of the session. A cookie usually only works with browsers and is not mobile app friendly.
+- Kirishning hayotiy siklini yanada nozik nazorat qilish - bu seans-cookie. Server seans xotirasini saqlaydi, brauzer esa sessiya identifikatorini saqlaydi. Cookie odatda faqat brauzerlar bilan ishlaydi va mobil ilovaga mos kelmaydi.
-- To address the compatibility issue, the token can be used. The client sends the token to the server, and the server validates the token. The downside is that the token needs to be encrypted and decrypted, which may be time-consuming.
+- Moslik muammosini hal qilish uchun tokendan foydalanish mumkin. Mijoz tokenni serverga yuboradi va server tokenni tasdiqlaydi. Salbiy tomoni shundaki, token shifrlanishi va shifrlanishi kerak, bu ko'p vaqt talab qilishi mumkin.
-- JWT is a standard way of representing tokens. This information can be verified and trusted because it is digitally signed. Since JWT contains the signature, there is no need to save session information on the server side.
+- JWT tokenlarni ifodalashning standart usulidir. Ushbu ma'lumot raqamli imzolanganligi sababli tekshirilishi va ishonchli bo'lishi mumkin. JWT imzoni o'z ichiga olganligi sababli, sessiya ma'lumotlarini server tomonida saqlashga hojat yo'q.
-- By using SSO (single sign-on), you can sign on only once and log in to multiple websites. It uses CAS (central authentication service) to maintain cross-site information.
+- SSO (bitta tizimga kirish) yordamida siz faqat bir marta tizimga kirishingiz va bir nechta veb-saytlarga kirishingiz mumkin. U saytlararo ma'lumotlarni saqlash uchun CAS (markaziy autentifikatsiya xizmati) dan foydalanadi.
-- By using OAuth 2.0, you can authorize one website to access your information on another website.
+- OAuth 2.0 dan foydalanib, siz bitta veb-saytga boshqa veb-saytdagi ma'lumotlaringizga kirishga ruxsat berishingiz mumkin.
### Ma'lumotlar bazasida parollarni qanday xavfsiz saqlash va parolni qanday tekshirish mumkin?
@@ -1408,31 +1406,31 @@ From simple to complex, here is my understanding of user identity management:
-**Things NOT to do**
+**Qilinmaydigan narsalar**
-- Storing passwords in plain text is not a good idea because anyone with internal access can see them.
+- Parollarni oddiy matnda saqlash yaxshi fikr emas, chunki ichki kirish huquqiga ega bo'lgan har bir kishi ularni ko'rishi mumkin.
-- Storing password hashes directly is not sufficient because it is pruned to precomputation attacks, such as rainbow tables.
+- Parol xeshlarini to'g'ridan-to'g'ri saqlash etarli emas, chunki u kamalak jadvallari kabi oldindan hisoblash hujumlari uchun kesilgan.
-- To mitigate precomputation attacks, we salt the passwords.
+- Oldindan hisoblash hujumlarini yumshatish uchun biz parollarni tuzlaymiz.
-**What is salt?**
+**Tuz (salt) nima??**
-According to OWASP guidelines, “a salt is a unique, randomly generated string that is added to each password as part of the hashing process”.
+OWASP ko'rsatmalariga ko'ra, "tuz - bu xeshlash jarayonining bir qismi sifatida har bir parolga qo'shiladigan noyob, tasodifiy yaratilgan satr".
-**How to store a password and salt?**
+**Parol va tuzni qanday saqlash kerak?**
-1. the hash result is unique to each password.
-1. The password can be stored in the database using the following format: hash(password + salt).
+1. xesh natijasi har bir parol uchun noyobdir.
+1. Parol ma'lumotlar bazasida quyidagi formatda saqlanishi mumkin: hash(parol + tuz).
-**How to validate a password?**
+**Parolni qanday tekshirish mumkin?**
-To validate a password, it can go through the following process:
+Parolni tasdiqlash uchun u quyidagi jarayondan o'tishi mumkin:
-1. A client enters the password.
-1. The system fetches the corresponding salt from the database.
-1. The system appends the salt to the password and hashes it. Let’s call the hashed value H1.
-1. The system compares H1 and H2, where H2 is the hash stored in the database. If they are the same, the password is valid.
+1. Mijoz parolni kiritadi.
+2. Tizim ma'lumotlar bazasidan mos keladigan tuzni oladi.
+3. Tizim tuzni parolga qo'shib, uni xeshlaydi. Xeshlangan qiymatni H1 deb ataymiz.
+4. Tizim H1 va H2 ni taqqoslaydi, bu erda H2 ma'lumotlar bazasida saqlangan xeshdir. Agar ular bir xil bo'lsa, parol haqiqiy hisoblanadi.
### 10 yoshli bolaga JSON Web Token (JWT) haqida tushuntirish
@@ -1440,57 +1438,60 @@ To validate a password, it can go through the following process:
-Imagine you have a special box called a JWT. Inside this box, there are three parts: a header, a payload, and a signature.
+Tasavvur qiling-a, sizda JWT deb nomlangan maxsus quti bor. Ushbu qutining ichida uchta qism mavjud: sarlavha, foydali yuk va imzo.
-The header is like the label on the outside of the box. It tells us what type of box it is and how it's secured. It's usually written in a format called JSON, which is just a way to organize information using curly braces { } and colons : .
+Sarlavha qutining tashqi tomonidagi yorliq kabi. U qanday turdagi quti ekanligini va qanday himoyalanganligini aytadi. U odatda JSON deb nomlangan formatda yoziladi, bu shunchaki jingalak qavslar { } va ikki nuqta : yordamida ma'lumotni tartibga solish usulidir.
-The payload is like the actual message or information you want to send. It could be your name, age, or any other data you want to share. It's also written in JSON format, so it's easy to understand and work with.
-Now, the signature is what makes the JWT secure. It's like a special seal that only the sender knows how to create. The signature is created using a secret code, kind of like a password. This signature ensures that nobody can tamper with the contents of the JWT without the sender knowing about it.
+Foydali yuk siz yubormoqchi bo'lgan haqiqiy xabar yoki ma'lumotga o'xshaydi. Bu sizning ismingiz, yoshingiz yoki siz baham ko'rmoqchi bo'lgan boshqa ma'lumotlar bo'lishi mumkin. U JSON formatida ham yozilgan, shuning uchun uni tushunish va ishlash oson.
+Endi imzo JWTni xavfsiz qiladi. Bu maxsus muhrga o'xshaydi, uni qanday yaratishni faqat jo'natuvchi biladi. Imzo parol kabi maxfiy kod yordamida yaratiladi. Ushbu imzo jo'natuvchi bu haqda bilmasdan JWT mazmunini hech kim o'zgartira olmasligini ta'minlaydi.
-When you want to send the JWT to a server, you put the header, payload, and signature inside the box. Then you send it over to the server. The server can easily read the header and payload to understand who you are and what you want to do.
+JWT-ni serverga yubormoqchi bo'lganingizda, siz sarlavhani, foydali yukni va imzoni qutiga qo'yasiz. Keyin uni serverga yuborasiz. Server sizning kimligingizni va nima qilishni xohlayotganingizni tushunish uchun sarlavha va foydali yukni osongina o'qiy oladi.
### Google Authenticator (yoki 2 faktorli autentifikatsiyaning boshqa turlari) qanday ishlaydi?
+Ikki bosqich mavjud: 1-bosqich - foydalanuvchi Google ikki bosqichli tekshiruvini yoqadi. 2-bosqich - foydalanuvchi tizimga kirish uchun autentifikatordan foydalanadi va hokazo.
-Google Authenticator is commonly used for logging into our accounts when 2-factor authentication is enabled. How does it guarantee security?
+Google Authenticator odatda 2 faktorli autentifikatsiya yoqilganda hisobimizga kirish uchun ishlatiladi. Qanday qilib u xavfsizlikni kafolatlaydi?
-Google Authenticator is a software-based authenticator that implements a two-step verification service. The diagram below provides detail.
+Google Authenticator - bu ikki bosqichli tekshirish xizmatini amalga oshiradigan dasturiy ta'minotga asoslangan autentifikatsiya. Quyidagi diagrammada batafsil ma'lumot berilgan.
-There are two stages involved:
+Ikki bosqich mavjud
-- Stage 1 - The user enables Google two-step verification.
-- Stage 2 - The user uses the authenticator for logging in, etc.
+- 1-bosqich - foydalanuvchi Google ikki bosqichli tekshiruvini yoqadi.
+- 2-bosqich - foydalanuvchi tizimga kirish uchun autentifikatordan foydalanadi va hokazo.
-Let’s look at these stages.
+Keling, ushbu bosqichlarni ko'rib chiqaylik.
-**Stage 1**
+**1-bosqich**
-Steps 1 and 2: Bob opens the web page to enable two-step verification. The front end requests a secret key. The authentication service generates the secret key for Bob and stores it in the database.
+1 va 2-qadamlar: Bob ikki bosqichli tekshiruvni yoqish uchun veb-sahifani ochadi. Old tomon maxfiy kalitni so'raydi. Autentifikatsiya xizmati Bob uchun maxfiy kalitni yaratadi va uni ma'lumotlar bazasida saqlaydi.
+
+3-qadam: Autentifikatsiya xizmati URI-ni old tomonga qaytaradi. URI kalit emitent, foydalanuvchi nomi va maxfiy kalitdan iborat. URI veb-sahifada QR kod ko'rinishida ko'rsatiladi.
-Step 3: The authentication service returns a URI to the front end. The URI is composed of a key issuer, username, and secret key. The URI is displayed in the form of a QR code on the web page.
+3-qadam: Autentifikatsiya xizmati URI-ni old tomonga qaytaradi. URI kalit emitent, foydalanuvchi nomi va maxfiy kalitdan iborat. URI veb-sahifada QR kod ko'rinishida ko'rsatiladi.
-Step 4: Bob then uses Google Authenticator to scan the generated QR code. The secret key is stored in the authenticator.
+4-qadam: Keyin Bob yaratilgan QR kodni skanerlash uchun Google Authenticator-dan foydalanadi. Maxfiy kalit autentifikatorda saqlanadi.
-**Stage 2**
-Steps 1 and 2: Bob wants to log into a website with Google two-step verification. For this, he needs the password. Every 30 seconds, Google Authenticator generates a 6-digit password using TOTP (Time-based One Time Password) algorithm. Bob uses the password to enter the website.
+**2-bosqich**
+1 va 2-qadamlar: Bob Google ikki bosqichli tekshiruvi bilan veb-saytga kirmoqchi. Buning uchun unga parol kerak. Har 30 soniyada Google Authenticator TOTP (Vaqtga asoslangan bir martalik parol) algoritmi yordamida 6 xonali parolni yaratadi. Bob veb-saytga kirish uchun paroldan foydalanadi.
-Steps 3 and 4: The frontend sends the password Bob enters to the backend for authentication. The authentication service reads the secret key from the database and generates a 6-digit password using the same TOTP algorithm as the client.
+3 va 4-qadamlar: Frontend autentifikatsiya qilish uchun Bob kiritgan parolni backendga yuboradi. Autentifikatsiya xizmati ma'lumotlar bazasidan maxfiy kalitni o'qiydi va mijoz bilan bir xil TOTP algoritmidan foydalangan holda 6 xonali parolni yaratadi.
-Step 5: The authentication service compares the two passwords generated by the client and the server, and returns the comparison result to the frontend. Bob can proceed with the login process only if the two passwords match.
+5-qadam: Autentifikatsiya xizmati mijoz va server tomonidan yaratilgan ikkita parolni solishtiradi va taqqoslash natijasini frontendga qaytaradi. Bob kirish jarayonini faqat ikkita parol mos kelgan taqdirdagina davom ettirishi mumkin.
-Is this authentication mechanism safe?
+Ushbu autentifikatsiya mexanizmi xavfsizmi?
-- Can the secret key be obtained by others?
+- Yashirin kalitni boshqalar olishi mumkinmi?
- We need to make sure the secret key is transmitted using HTTPS. The authenticator client and the database store the secret key, and we need to make sure the secret keys are encrypted.
+ Yashirin kalit HTTPS orqali uzatilishiga ishonch hosil qilishimiz kerak. Autentifikatsiya mijozi va ma'lumotlar bazasi maxfiy kalitni saqlaydi va biz maxfiy kalitlar shifrlanganligiga ishonch hosil qilishimiz kerak.
-- Can the 6-digit password be guessed by hackers?
+- 6 xonali parolni xakerlar taxmin qilishlari mumkinmi?
- No. The password has 6 digits, so the generated password has 1 million potential combinations. Plus, the password changes every 30 seconds. If hackers want to guess the password in 30 seconds, they need to enter 30,000 combinations per second.
+ Yo'q. Parol 6 ta raqamga ega, shuning uchun yaratilgan parol 1 million potentsial kombinatsiyaga ega. Bundan tashqari, parol har 30 soniyada o'zgaradi. Agar xakerlar parolni 30 soniya ichida taxmin qilmoqchi bo'lsa, ular soniyasiga 30 000 ta kombinatsiyani kiritishlari kerak.
## Haqiqiy dunyo misollari
From f95cd380e61dccfc11b4d81048cc1744b2cb17c0 Mon Sep 17 00:00:00 2001
From: realtemirov
Date: Fri, 24 Nov 2023 15:54:32 +0500
Subject: [PATCH 7/8] ready
---
translations/README-uz.md | 192 +++++++++++++++++++-------------------
1 file changed, 96 insertions(+), 96 deletions(-)
diff --git a/translations/README-uz.md b/translations/README-uz.md
index 6c00719..c8df702 100644
--- a/translations/README-uz.md
+++ b/translations/README-uz.md
@@ -1498,31 +1498,31 @@ Ushbu autentifikatsiya mexanizmi xavfsizmi?
### Netflixning Tech Stacki
-This post is based on research from many Netflix engineering blogs and open-source projects. If you come across any inaccuracies, please feel free to inform us.
+Ushbu post ko'plab Netflix muhandislik bloglari va ochiq manba loyihalari tadqiqotlariga asoslangan. Agar biron bir noaniqliklarga duch kelsangiz, iltimos, bizga xabar bering.
-**Mobile and web**: Netflix has adopted Swift and Kotlin to build native mobile apps. For its web application, it uses React.
+**Mobil va veb**: Netflix mahalliy mobil ilovalarni yaratish uchun Swift va Kotlinni qabul qildi. O'zining veb-ilovasi uchun u React-dan foydalanadi.
-**Frontend/server communication**: Netflix uses GraphQL.
+**Frontend/server aloqasi**: Netflix GraphQL-dan foydalanadi.
-**Backend services**: Netflix relies on ZUUL, Eureka, the Spring Boot framework, and other technologies.
+**Backend xizmatlari**: Netflix ZUUL, Eureka, Spring Boot ramkasi va boshqa texnologiyalarga tayanadi.
-**Databases**: Netflix utilizes EV cache, Cassandra, CockroachDB, and other databases.
+**Ma'lumotlar bazalari**: Netflix EV keshi, Cassandra, CockroachDB va boshqa ma'lumotlar bazalaridan foydalanadi.
-**Messaging/streaming**: Netflix employs Apache Kafka and Fink for messaging and streaming purposes.
+**Xabar almashish/striming**: Netflix xabar almashish va oqimlash uchun Apache Kafka va Fink-dan foydalanadi.
-**Video storage**: Netflix uses S3 and Open Connect for video storage.
+**Video saqlash**: Netflix video saqlash uchun S3 va Open Connect-dan foydalanadi.
-**Data processing**: Netflix utilizes Flink and Spark for data processing, which is then visualized using Tableau. Redshift is used for processing structured data warehouse information.
+**Ma'lumotlarni qayta ishlash**: Netflix ma'lumotlarni qayta ishlash uchun Flink va Spark-dan foydalanadi, keyin esa Tableau yordamida vizualizatsiya qilinadi. Redshift tuzilgan ma'lumotlar ombori ma'lumotlarini qayta ishlash uchun ishlatiladi.
-**CI/CD**: Netflix employs various tools such as JIRA, Confluence, PagerDuty, Jenkins, Gradle, Chaos Monkey, Spinnaker, Atlas, and more for CI/CD processes.
+**CI/CD**: Netflix CI/CD jarayonlari uchun JIRA, Confluence, PagerDuty, Jenkins, Gradle, Chaos Monkey, Spinnaker, Atlas va boshqalar kabi turli xil vositalardan foydalanadi.
### Twitter arxitekturasi 2022
-Yes, this is the real Twitter architecture. It is posted by Elon Musk and redrawn by us for better readability.
+Ha, bu haqiqiy Twitter arxitekturasi. U Elon Mask tomonidan joylashtirilgan va biz uni yaxshiroq o'qish uchun qayta chizganmiz.
@@ -1531,128 +1531,128 @@ Yes, this is the real Twitter architecture. It is posted by Elon Musk and redraw
### Oxirgi 15 yil ichida Airbnb mikroservis arxitekturasining evolyutsiyasi
-Airbnb’s microservice architecture went through 3 main stages.
+Airbnb mikroservis arxitekturasi 3 asosiy bosqichdan o'tdi.
-Monolith (2008 - 2017)
+Monolit (2008 - 2017)
-Airbnb began as a simple marketplace for hosts and guests. This is built in a Ruby on Rails application - the monolith.
+Airbnb mezbonlar va mehmonlar uchun oddiy bozor sifatida boshlangan. Bu Ruby on Rails ilovasida - monolitda qurilgan.
-What’s the challenge?
+Qiyinchilik nima?
-- Confusing team ownership + unowned code
-- Slow deployment
+- Chalkash jamoa egaligi + egaliksiz kod
+- Sekin joylashtirish
-Microservices (2017 - 2020)
+Mikroservislar (2017 - 2020)
-Microservice aims to solve those challenges. In the microservice architecture, key services include:
+Microservice ushbu muammolarni hal qilishga qaratilgan. Mikroservis arxitekturasida asosiy xizmatlarga quyidagilar kiradi:
-- Data fetching service
-- Business logic data service
-- Write workflow service
-- UI aggregation service
-- Each service had one owning team
+- Ma'lumot olish xizmati
+- Biznes mantiqiy ma'lumotlar xizmati
+- Ish jarayonini yozish xizmati
+- UI yig'ish xizmati
+- Har bir xizmatning bitta egasi bor edi
-What’s the challenge?
+Qiyinchilik nima?
-Hundreds of services and dependencies were difficult for humans to manage.
+Yuzlab xizmatlar va qaramliklarni boshqarish odamlar uchun qiyin edi.
-Micro + macroservices (2020 - present)
+Micro + makroservislar (2020 yildan hozirgi kungacha)
-This is what Airbnb is working on now. The micro and macroservice hybrid model focuses on the unification of APIs.
+Hozirda Airbnb shu narsa ustida ishlamoqda. Mikro va makroservis gibrid modeli asosiy e'tibor API larni birlashtirishga qaratilgan.
### Monorepo va mikrorepo.
-Which is the best? Why do different companies choose different options?
+Qaysi biri eng yaxshisi? Nima uchun turli kompaniyalar turli xil variantlarni tanlaydilar?
-Monorepo isn't new; Linux and Windows were both created using Monorepo. To improve scalability and build speed, Google developed its internal dedicated toolchain to scale it faster and strict coding quality standards to keep it consistent.
+Monorepo yangi emas; Linux va Windows ikkalasi ham Monorepo yordamida yaratilgan. Kengaytirish va qurish tezligini yaxshilash uchun Google uni tezroq kengaytirish uchun ichki maxsus asboblar zanjirini va uni izchil saqlash uchun qattiq kodlash sifat standartlarini ishlab chiqdi.
-Amazon and Netflix are major ambassadors of the Microservice philosophy. This approach naturally separates the service code into separate repositories. It scales faster but can lead to governance pain points later on.
+Amazon va Netflix Microservice falsafasining asosiy elchilaridir. Ushbu yondashuv tabiiy ravishda xizmat kodini alohida omborlarga ajratadi. U tezroq tarqaladi, lekin keyinchalik boshqaruvning og'riqli nuqtalariga olib kelishi mumkin.
-Within Monorepo, each service is a folder, and every folder has a BUILD config and OWNERS permission control. Every service member is responsible for their own folder.
+Monorepo ichida har bir xizmat papka bo'lib, har bir jildda BUILD konfiguratsiyasi va HONERS ruxsati boshqaruvi mavjud. Har bir xizmatchi o'z papkasi uchun javobgardir.
-On the other hand, in Microrepo, each service is responsible for its repository, with the build config and permissions typically set for the entire repository.
+Boshqa tomondan, Microrepo-da har bir xizmat o'z ombori uchun javobgar bo'lib, qurish konfiguratsiyasi va ruxsatlar odatda butun ombor uchun o'rnatiladi.
-In Monorepo, dependencies are shared across the entire codebase regardless of your business, so when there's a version upgrade, every codebase upgrades their version.
+Monorepo-da bog'liqliklar biznesingizdan qat'i nazar, butun kod bazasi bo'ylab taqsimlanadi, shuning uchun versiyani yangilash mavjud bo'lganda, har bir kod bazasi o'z versiyasini yangilaydi.
-In Microrepo, dependencies are controlled within each repository. Businesses choose when to upgrade their versions based on their own schedules.
+Microrepo-da bog'liqliklar har bir ombor ichida nazorat qilinadi. Korxonalar o'z jadvallari asosida o'z versiyalarini qachon yangilashni tanlashadi.
-Monorepo has a standard for check-ins. Google's code review process is famously known for setting a high bar, ensuring a coherent quality standard for Monorepo, regardless of the business.
+Monorepoda ro'yxatdan o'tish uchun standart mavjud. Google-ning kodni ko'rib chiqish jarayoni biznesdan qat'i nazar, Monorepo uchun izchil sifat standartini ta'minlaydigan yuqori barni o'rnatishi bilan mashhur.
-Microrepo can either set its own standard or adopt a shared standard by incorporating the best practices. It can scale faster for business, but the code quality might be a bit different.
-Google engineers built Bazel, and Meta built Buck. There are other open-source tools available, including Nix, Lerna, and others.
+Microrepo o'z standartini o'rnatishi yoki eng yaxshi tajribalarni o'z ichiga olgan umumiy standartni qabul qilishi mumkin. U biznes uchun tezroq kengayishi mumkin, ammo kod sifati biroz boshqacha bo'lishi mumkin.
+Google muhandislari Bazelni, Meta esa Bakni yaratdi. Boshqa ochiq manbali vositalar mavjud, jumladan Nix, Lerna va boshqalar.
-Over the years, Microrepo has had more supported tools, including Maven and Gradle for Java, NPM for NodeJS, and CMake for C/C++, among others.
+Yillar davomida Microrepo ko'proq qo'llab-quvvatlanadigan vositalarga ega bo'ldi, jumladan Java uchun Maven va Gradle, NodeJS uchun NPM va C/C++ uchun CMake va boshqalar.
### Stack Overflow veb-saytini qanday loyihalashtirasiz?
-If your answer is on-premise servers and monolith (on the bottom of the following image), you would likely fail the interview, but that's how it is built in reality!
+Agar sizning javobingiz mahalliy serverlar va monolit (quyidagi rasmning pastki qismida) bo'lsa, siz intervyuda muvaffaqiyatsiz bo'lishingiz mumkin, ammo u haqiqatda shunday qurilgan!
-**What people think it should look like**
+**Odamlar qanday ko'rinishi kerak deb o'ylashadi**
-The interviewer is probably expecting something like the top portion of the picture.
+Suhbatdosh, ehtimol, rasmning yuqori qismiga o'xshash narsani kutmoqda.
-- Microservice is used to decompose the system into small components.
-- Each service has its own database. Use cache heavily.
-- The service is sharded.
-- The services talk to each other asynchronously through message queues.
-- The service is implemented using Event Sourcing with CQRS.
-- Showing off knowledge in distributed systems such as eventual consistency, CAP theorem, etc.
+- Mikroservis tizimni kichik qismlarga ajratish uchun ishlatiladi.
+- Har bir xizmat o'z ma'lumotlar bazasiga ega. Keshni qattiq ishlating.
+- Xizmat ajratilgan.
+- Xizmatlar bir-biri bilan asinxron tarzda xabarlar navbatlari orqali gaplashadi.
+- Xizmat CQRS bilan Event Sourcing yordamida amalga oshiriladi.
+- Taqsimlangan tizimlarda bilimlarni namoyish qilish, masalan, yakuniy izchillik, CAP teoremasi va boshqalar.
-**What it actually is**
+**Bu aslida nima**
-Stack Overflow serves all the traffic with only 9 on-premise web servers, and it’s on monolith! It has its own servers and does not run on the cloud.
+Stack Overflow barcha trafikni faqat 9 ta mahalliy veb-serverlar bilan ta'minlaydi va u monolitda! Uning o'z serverlari bor va bulutda ishlamaydi.
-This is contrary to all our popular beliefs these days.
+Bu bizning barcha mashhur e'tiqodlarimizga ziddir.
### Nima uchun Amazon Prime Video monitoringi serversizdan monolitga o'tdi? Qanday qilib 90% xarajatlarni tejash mumkin?
-The diagram below shows the architecture comparison before and after the migration.
+Quyidagi diagrammada migratsiyadan oldin va keyin arxitektura taqqoslash ko'rsatilgan.
-What is Amazon Prime Video Monitoring Service?
+Amazon Prime Video Monitoring xizmati nima?
-Prime Video service needs to monitor the quality of thousands of live streams. The monitoring tool automatically analyzes the streams in real time and identifies quality issues like block corruption, video freeze, and sync problems. This is an important process for customer satisfaction.
+Prime Video xizmati minglab jonli translatsiyalar sifatini kuzatishi kerak. Monitoring vositasi real vaqtda oqimlarni avtomatik ravishda tahlil qiladi va blokirovka buzilishi, videoni muzlatish va sinxronlash muammolari kabi sifat muammolarini aniqlaydi. Bu mijozlar ehtiyojini qondirish uchun muhim jarayon.
-There are 3 steps: media converter, defect detector, and real-time notification.
+3 bosqich mavjud: media konvertori, nuqsonlarni aniqlovchi va real vaqtda bildirishnoma.
-- What is the problem with the old architecture?
+- Eski arxitekturada qanday muammo bor?
- The old architecture was based on Amazon Lambda, which was good for building services quickly. However, it was not cost-effective when running the architecture at a high scale. The two most expensive operations are:
+ Qadimgi arxitektura Amazon Lambda-ga asoslangan bo'lib, u tezda xizmatlarni qurish uchun yaxshi edi. Biroq, arxitekturani yuqori miqyosda ishga tushirishda bu iqtisodiy jihatdan samarali emas edi. Ikkita eng qimmat operatsiya:
-1. The orchestration workflow - AWS step functions charge users by state transitions and the orchestration performs multiple state transitions every second.
+1. Orkestratsiya ish oqimi - AWS qadam funktsiyalari foydalanuvchilarni holat o'tishlari bo'yicha to'laydi va orkestr har soniyada bir nechta holat o'tishlarini amalga oshiradi.
-2. Data passing between distributed components - the intermediate data is stored in Amazon S3 so that the next stage can download. The download can be costly when the volume is high.
+2. Taqsimlangan komponentlar o'rtasida ma'lumotlar uzatish - oraliq ma'lumotlar Amazon S3 da saqlanadi, shunda keyingi bosqich yuklab olinadi. Ovoz balandligi baland bo'lsa, yuklab olish qimmatga tushishi mumkin.
-- Monolithic architecture saves 90% cost
+- Monolitik arxitektura 90% xarajatlarni tejaydi
- A monolithic architecture is designed to address the cost issues. There are still 3 components, but the media converter and defect detector are deployed in the same process, saving the cost of passing data over the network. Surprisingly, this approach to deployment architecture change led to 90% cost savings!
+ Monolitik arxitektura xarajatlar bilan bog'liq muammolarni hal qilish uchun mo'ljallangan. Hali ham 3 ta komponent mavjud, biroq media konvertor va nuqson detektori bir xil jarayonda joylashtiriladi, bu esa tarmoq orqali ma'lumotlarni uzatish xarajatlarini tejaydi. Ajablanarlisi shundaki, joylashtirish arxitekturasini o'zgartirishga bunday yondashuv xarajatlarni 90% tejashga olib keldi!
-This is an interesting and unique case study because microservices have become a go-to and fashionable choice in the tech industry. It's good to see that we are having more discussions about evolving the architecture and having more honest discussions about its pros and cons. Decomposing components into distributed microservices comes with a cost.
+Bu qiziqarli va noyob misoldir, chunki mikroservislar texnologiya sanoatida mashhur va moda tanloviga aylandi. Biz arxitekturani rivojlantirish va uning ijobiy va salbiy tomonlari haqida ko'proq halol muhokamalar olib borayotganimizni ko'rish juda yaxshi. Komponentlarni taqsimlangan mikroservislarga ajratish qimmatga tushadi.
-- What did Amazon leaders say about this?
+- Amazon rahbarlari bu haqda nima dedilar?
- Amazon CTO Werner Vogels: “Building **evolvable software systems** is a strategy, not a religion. And revisiting your architecture with an open mind is a must.”
+ Amazon CTO Verner Vogels: "**Rivojlanuvchan dasturiy ta'minot tizimlarini** yaratish din emas, balki strategiyadir. Va arxitekturangizni ochiq fikr bilan qayta ko'rib chiqish shart.".
-Ex Amazon VP Sustainability Adrian Cockcroft: “The Prime Video team had followed a path I call **Serverless First**…I don’t advocate **Serverless Only**”.
+Amazonning Barqarorlik bo'yicha sobiq vitse-prezidenti Adrian Kokkroft: "Prime Video jamoasi men **birinchi bo'lib Serversiz** deb ataydigan yo'ldan bordi... Men Faqat **Serversizni** yoqlamayman".
### Disney Hotstar turnir davomida 5 milliard kulgichni qanday suratga oladi?
@@ -1661,23 +1661,23 @@ Ex Amazon VP Sustainability Adrian Cockcroft: “The Prime Video team had follow
-1. Clients send emojis through standard HTTP requests. You can think of Golang Service as a typical Web Server. Golang is chosen because it supports concurrency well. Threads in Golang are lightweight.
+1. Mijozlar emojilarni standart HTTP so'rovlari orqali yuboradilar. Golang xizmatini odatiy veb-server sifatida tasavvur qilishingiz mumkin. Golang tanlangan, chunki u parallellikni yaxshi qo'llab-quvvatlaydi. Golangdagi iplar engildir.
-2. Since the write volume is very high, Kafka (message queue) is used as a buffer.
+2. Yozish hajmi juda yuqori bo'lgani uchun bufer sifatida Kafka (xabar navbati) ishlatiladi.
-3. Emoji data are aggregated by a streaming processing service called Spark. It aggregates data every 2 seconds, which is configurable. There is a trade-off to be made based on the interval. A shorter interval means emojis are delivered to other clients faster but it also means more computing resources are needed.
+3. Emoji ma'lumotlari Spark deb nomlangan oqimni qayta ishlash xizmati tomonidan jamlanadi. U sozlanishi mumkin bo'lgan har 2 soniyada ma'lumotlarni jamlaydi. Interval asosida amalga oshiriladigan savdo-sotiq mavjud. Qisqaroq intervalli emojilar boshqa mijozlarga tezroq yetkazilishini anglatadi, lekin bu ko'proq hisoblash resurslari kerakligini anglatadi.
-4. Aggregated data is written to another Kafka.
+4. Yig'ilgan ma'lumotlar boshqa Kafkaga yoziladi.
-5. The PubSub consumers pull aggregated emoji data from Kafka.
+5. PubSub iste'molchilari Kafkadan jamlangan emoji ma'lumotlarini olishadi.
-6. Emojis are delivered to other clients in real-time through the PubSub infrastructure. The PubSub infrastructure is interesting. Hotstar considered the following protocols: Socketio, NATS, MQTT, and gRPC, and settled with MQTT.
+6. Emojilar boshqa mijozlarga real vaqt rejimida PubSub infratuzilmasi orqali yetkaziladi. PubSub infratuzilmasi qiziqarli. Hotstar quyidagi protokollarni ko'rib chiqdi: Socketio, NATS, MQTT va gRPC va MQTT bilan hisob-kitob qildi.
-A similar design is adopted by LinkedIn which streams a million likes/sec.
+Shunga o'xshash dizayn LinkedIn tomonidan qabul qilingan bo'lib, u sekundiga millionlab yoqtirishlarni oladi.
### Discord qanday qilib trillionlab xabarlarni saqlaydi?
-The diagram below shows the evolution of message storage at Discord:
+Quyidagi diagrammada Discord-da xabarlarni saqlash evolyutsiyasi ko'rsatilgan:
@@ -1686,54 +1686,54 @@ The diagram below shows the evolution of message storage at Discord:
MongoDB ➡️ Cassandra ➡️ ScyllaDB
-In 2015, the first version of Discord was built on top of a single MongoDB replica. Around Nov 2015, MongoDB stored 100 million messages and the RAM couldn’t hold the data and index any longer. The latency became unpredictable. Message storage needs to be moved to another database. Cassandra was chosen.
+2015 yilda Discord-ning birinchi versiyasi bitta MongoDB nusxasi ustiga qurilgan. Taxminan 2015 yil noyabr oyida MongoDB 100 million xabarni saqladi va operativ xotira ma'lumotlarni va indeksni boshqa saqlay olmadi. Kechikish oldindan aytib bo'lmaydigan bo'lib qoldi. Xabarni saqlash boshqa ma'lumotlar bazasiga ko'chirilishi kerak. Kassandra tanlandi.
-In 2017, Discord had 12 Cassandra nodes and stored billions of messages.
+2017 yilda Discord 12 ta Cassandra tuguniga ega bo'lib, milliardlab xabarlarni saqlagan.
-At the beginning of 2022, it had 177 nodes with trillions of messages. At this point, latency was unpredictable, and maintenance operations became too expensive to run.
+2022 yil boshida u trillionlab xabarlarga ega 177 tugunga ega edi. Bu vaqtda kechikishni oldindan aytib bo'lmaydi va texnik xizmat ko'rsatish operatsiyalari bajarish uchun juda qimmatga tushdi.
-There are several reasons for the issue:
+Muammoning bir nechta sabablari bor:
-- Cassandra uses the LSM tree for the internal data structure. The reads are more expensive than the writes. There can be many concurrent reads on a server with hundreds of users, resulting in hotspots.
-- Maintaining clusters, such as compacting SSTables, impacts performance.
-- Garbage collection pauses would cause significant latency spikes
+- Kassandra ichki ma'lumotlar tuzilishi uchun LSM daraxtidan foydalanadi. O'qishlar yozishdan qimmatroq. Yuzlab foydalanuvchilari bo'lgan serverda bir vaqtning o'zida ko'plab o'qishlar bo'lishi mumkin, natijada ulanish nuqtalari paydo bo'ladi.
+- Klasterlarni saqlash, masalan, SSTablelarni ixchamlashtirish, ishlashga ta'sir qiladi.
+- Axlat yig'ish to'xtatilishi sezilarli kechikishlarga olib keladi
-ScyllaDB is Cassandra compatible database written in C++. Discord redesigned its architecture to have a monolithic API, a data service written in Rust, and ScyllaDB-based storage.
+ScyllaDB - bu C++ da yozilgan Cassandra mos ma'lumotlar bazasi. Discord o'z arxitekturasini monolit API, Rust-da yozilgan ma'lumotlar xizmati va ScyllaDB-ga asoslangan saqlash uchun qayta ishlab chiqdi.
-The p99 read latency in ScyllaDB is 15ms compared to 40-125ms in Cassandra. The p99 write latency is 5ms compared to 5-70ms in Cassandra.
+ScyllaDB-da p99 o'qish kechikishi Cassandra-da 40-125ms bilan solishtirganda 15ms ni tashkil qiladi. p99 yozish kechikishi Kassandrada 5-70 ms ga nisbatan 5 ms ni tashkil qiladi.
### YouTube, TikTok live yoki Twitch-da jonli video oqimlari qanday ishlaydi?
-Live streaming differs from regular streaming because the video content is sent via the internet in real-time, usually with a latency of just a few seconds.
+Jonli translatsiya oddiy oqimdan farq qiladi, chunki video kontent real vaqtda internet orqali yuboriladi, odatda bir necha soniya kechikish bilan.
-The diagram below explains what happens behind the scenes to make this possible.
+Quyidagi diagramma buni amalga oshirish uchun sahna ortida nima sodir bo'lishini tushuntiradi.
-Step 1: The raw video data is captured by a microphone and camera. The data is sent to the server side.
+1-qadam: Xom video ma'lumotlari mikrofon va kamera tomonidan olinadi. Ma'lumotlar server tomoniga yuboriladi.
-Step 2: The video data is compressed and encoded. For example, the compressing algorithm separates the background and other video elements. After compression, the video is encoded to standards such as H.264. The size of the video data is much smaller after this step.
+2-qadam: Video ma'lumotlar siqiladi va kodlanadi. Masalan, siqish algoritmi fon va boshqa video elementlarini ajratib turadi. Siqilgandan so'ng, video H.264 kabi standartlarga kodlangan. Ushbu bosqichdan so'ng video ma'lumotlarining hajmi ancha kichik bo'ladi.
-Step 3: The encoded data is divided into smaller segments, usually seconds in length, so it takes much less time to download or stream.
+3-qadam: Kodlangan ma'lumotlar kichikroq segmentlarga bo'linadi, odatda uzunligi soniyalar, shuning uchun yuklab olish yoki oqimlash uchun juda kam vaqt talab etiladi.
-Step 4: The segmented data is sent to the streaming server. The streaming server needs to support different devices and network conditions. This is called ‘Adaptive Bitrate Streaming.’ This means we need to produce multiple files at different bitrates in steps 2 and 3.
+4-qadam: Segmentlangan ma'lumotlar oqim serveriga yuboriladi. Oqim serveri turli qurilmalar va tarmoq sharoitlarini qo'llab-quvvatlashi kerak. Bu "Adaptive Bitrate Streaming" deb ataladi. Bu 2 va 3-bosqichlarda turli bit tezligida bir nechta fayllarni ishlab chiqarishimiz kerakligini anglatadi.
-Step 5: The live streaming data is pushed to edge servers supported by CDN (Content Delivery Network.) Millions of viewers can watch the video from an edge server nearby. CDN significantly lowers data transmission latency.
+5-qadam: Jonli oqim ma'lumotlari CDN (Content Delivery Network.) tomonidan qo'llab-quvvatlanadigan chekka serverlarga uzatiladi. Millionlab tomoshabinlar videoni yaqin atrofdagi chekka serverdan ko'rishlari mumkin. CDN ma'lumotlar uzatish kechikishini sezilarli darajada kamaytiradi.
-Step 6: The viewers’ devices decode and decompress the video data and play the video in a video player.
+6-qadam: Tomoshabinlar qurilmalari video ma'lumotlarini dekodlaydi va ochadi va videoni video pleerda o'ynaydi.
-Steps 7 and 8: If the video needs to be stored for replay, the encoded data is sent to a storage server, and viewers can request a replay from it later.
+7 va 8-qadamlar: Agar videoni takrorlash uchun saqlash kerak bo'lsa, kodlangan ma'lumotlar saqlash serveriga yuboriladi va tomoshabinlar keyinchalik undan takrorlashni talab qilishlari mumkin.
-Standard protocols for live streaming include:
+Jonli efir uchun standart protokollarga quyidagilar kiradi:
-- RTMP (Real-Time Messaging Protocol): This was originally developed by Macromedia to transmit data between a Flash player and a server. Now it is used for streaming video data over the internet. Note that video conferencing applications like Skype use RTC (Real-Time Communication) protocol for lower latency.
-- HLS (HTTP Live Streaming): It requires the H.264 or H.265 encoding. Apple devices accept only HLS format.
-- DASH (Dynamic Adaptive Streaming over HTTP): DASH does not support Apple devices.
-- Both HLS and DASH support adaptive bitrate streaming.
+- RTMP (Real-Time Messaging Protocol): Bu dastlab Macromedia tomonidan Flash pleer va server o'rtasida ma'lumotlarni uzatish uchun ishlab chiqilgan. Endi u internet orqali video ma'lumotlarni uzatish uchun ishlatiladi. E'tibor bering, Skype kabi video konferentsiya ilovalari kamroq kechikish uchun RTC (Real-Time Communication) protokolidan foydalanadi.
+- HLS (HTTP Live Streaming): U H.264 yoki H.265 kodlashni talab qiladi. Apple qurilmalari faqat HLS formatini qabul qiladi.
+- DASH (HTTP orqali dinamik adaptiv oqim): DASH Apple qurilmalarini qo'llab-quvvatlamaydi.
+- HLS ham, DASH ham adaptiv bit tezligini qo'llab-quvvatlaydi.
## License
-This work is licensed under CC BY-NC-ND 4.0
+Ushbu ish CC BY-NC-ND 4.0 bo'yicha litsenziyalangan
From e907ecf1860429fce0d69ff6f3bc3354ba4f79c5 Mon Sep 17 00:00:00 2001
From: realtemirov
Date: Sun, 26 Nov 2023 16:16:16 +0500
Subject: [PATCH 8/8] bug fix
---
translations/README-uz.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/translations/README-uz.md b/translations/README-uz.md
index c8df702..ec18556 100644
--- a/translations/README-uz.md
+++ b/translations/README-uz.md
@@ -141,7 +141,7 @@ Arxitektura uslublari amaliy dasturlash interfeysining (API) turli komponentlari
- WebSocket:
- Real-time, bidirectional, persistent connections
+ Real vaqtda, ikki tomonlama, doimiy ulanishlar
Kam kechikishli ma'lumotlar almashinuvi uchun juda mos keladi
@@ -233,7 +233,7 @@ Shu tarzda, dasturlash paradigmasi o'zgartiriladi va to'lov xizmati endi to'lov
Agar PSP hech qachon qo'ng'iroq qilmasa nima bo'ladi? Biz har soatda to'lov holatini tekshirish uchun uy ishlarini o'rnatishimiz mumkin.
-WebhooksWebhuklar ko'pincha teskari API yoki push API deb ataladi, chunki server mijozga HTTP so'rovlarini yuboradi. Webhukdan foydalanishda 3 narsaga e'tibor qaratishimiz kerak:
+Webhuklar ko'pincha teskari API yoki push API deb ataladi, chunki server mijozga HTTP so'rovlarini yuboradi. Webhukdan foydalanishda 3 narsaga e'tibor qaratishimiz kerak:
1. Biz tashqi xizmat qo'ng'iroq qilish uchun tegishli APIni loyihalashimiz kerak.
2. Xavfsizlik nuqtai nazaridan API shlyuzida tegishli qoidalarni o'rnatishimiz kerak.
@@ -319,7 +319,7 @@ Kodni yozishdan va xizmatlar chegaralarini sinchkovlik bilan belgilashdan oldin
- Alohida funktsional guruhlar bir xil tilda gapirishlari kerak va maxsus funktsional guruhlar faqat o'zlarining tarkibiy qismlari va xizmatlari uchun javobgardir. Tashkilotga API dizayni orqali bir xil tilda gapirish tavsiya etiladi.
-Kod yozishdan oldin API dizaynini tasdiqlash uchun so'rovlar va javoblarni masxara qilishimiz mumkin.
+Kod yozishdan oldin API dizaynini tasdiqlash uchun so'rovlar va javoblarni haqiqiy bo'lmagan xomaki qilishimiz mumkin.
- Dasturiy ta'minot sifati va ishlab chiquvchining mahsuldorligini oshirish Loyiha boshlanganda noaniqliklarning ko'pini bartaraf etganimiz sababli, umumiy ishlab chiqish jarayoni yanada silliqlashadi va dasturiy ta'minot sifati sezilarli darajada yaxshilanadi.
@@ -405,7 +405,7 @@ Tarmoq modelida qatlamlar kerak, chunki har bir qatlam o'z mas'uliyatiga e'tibor
### Nima uchun Nginx "teskari" proksi-server deb ataladi?
-Quyidagi diagrammada 𝐟𝐨𝐫𝐰𝐚𝐫𝐝 𝐩𝐫𝐨𝐱𝐲 va 𝐫𝐞𝐯𝐞𝐫𝐬𝐞 𝐩𝐱𝐨 oʻrtasidagi farqlar koʻrsatilgan.
+Quyidagi diagrammada 𝐟𝐨𝐫𝐰𝐚𝐫𝐝 𝐩𝐫𝐨𝐱𝐲 va 𝐫𝐞𝐯𝐞𝐫𝐬𝐞 𝐩𝐫𝐨𝐱𝐲 oʻrtasidagi farqlar koʻrsatilgan.