Microservices are evil.
Yes, now I totally agree with JR ))

P.S. And I'm realizing this in a painful way.

Bugun bo'sh vaqtim ko'proq bo'lgani sabab o'zimni anchadan beri qiziqtirayotgan savollarga javob izlash va yana yangi kitob o'qishni boshlashga imkon bo'ldi.

Anchadan beri LinkedIn ishlatadigan Galene search engine (well, architecture) qanday ishlashiga qiziqayotgandim, bugun shu haqida ozroq ma'lumot topib (o'zi unchalik batafsil ma'lumot topa olmadim), o'qib ko'rdim. Xuddi kutganimdek, ancha murakkab tizim ekan.

Ko'pchilik backend engineerlar uchun database "shunchaki" ma'lumot saqlaydigan servis va bu qisman to'g'ri. Lekin tizimdan foydalanuvchilar minglab emas millionlab bo'lganida, ma'lumot hajmi gigabaytlar emas, petabaytlar bo'lganida hammasi o'zgaradi. Klassik qarashlar ortidan kelgan yechimlar ish bermay qoladi (xuddi kvant olamida klassik mexanika qoidalari ishlamaganidek). Yangicha yechim topish uchun muammoga boshqa tomonlardan qarab ko'rish kerak bo'ladi.

Nega LinkedIn faqatgina search (klassik CRUDning 1 ta elementi) qilishning o'zi uchun alohida engine ishlab chiqdi? Shunchaki bitta PostgreSQL instance yurgizib qo'yib, LIKE orqali search qilsa bo'lmasmidi?
Yo'q do'stim, hammasi bunchalik oddiy emas. Buning uchun biznes talablarini qondiradigan (har xil modellar ustida bitta query, natijalarni hudud, qiziqishlar, tanishlar kabi bir qancha metadata bo'yicha rank qilish, logik va grammatik alternativlar bo'yicha izlash, ...) va texnik jihatdan batafsil o'ylangan (latency, CPU va RAM limitlarini hisobga olish, ma'lumotlarni saqlash usulining storage va OS leveldagi muammolarini hisobga olish, optimizatsiya qilish, failurelar va attacklarga qarshi mexanizmlar bilan jihozlangan) tizim ishlab chiqish kerak bo'ladi. Va bu overengineering emas. Mana shu yerda esa "Database shunchaki ma'lumot saqlaydigan servis" degan gap o'zini oqlamaydi.

Ba'zan klassik muammolar oddiy, nozik yechim talab qiladi.

Masalan, MQ va Pub/Sub tizimlari duch keladigan klassik muammolardan biri latency va data persistency orasidagi "oldin nuqta"ni topish. Messagelarni memoryga yozish va o'qish tez, lekin persistencyni ta'minlash qiyin masala. Storagaga yozish ancha mustahkam yechim, lekin shu bilan birga ancha sekin.

Ko'pchilik MQlar (masalan, RabbitMQ) yuqoridagi ikkita yechimni ma'lum darajada birlashtirib, o'zlari uchun to'g'ri keladigan yechim ishlab chiqqan. Menga esa Kafka qo'llagan usul yoqadi. Xo'sh bu qanday yechim?
Shoshmang, yechimdan oldin muammoni yaxshilab tushunib olaylik.

Nega storagaga yozish/o'qish sekin?
Birinchidan, bu I/O operation, ikkinchidan storageda random access yo'q. Hajmi juda kichkina bo'lgan 100 ta message har xil joydagi 100 ta blokka yozilgan bo'lsa, ularni olish uchun 100 ta blokni to'liq yuklab olish, ya'ni 100 ta I/O kerak bo'ladi. Ya'ni bu usulning effektivligi past va sekin. Lekin agar o'sha 100 ta messageni ketma-ket turgan 2-3 ta bloklarga yozsakchi? Unda 100 ta message uchun 2/3 ta blokni o'qish yetarli bo'ladi. Va undan ham yaxshi tomoni, ketma-ket turgan bloklarni o'qish storagening narigi burchagida turgan blokni borib o'qishdan ko'ra tezroq bo'ladi. Kafka xuddi shunday qiladi. Ya'ni messagelarni storageda yonma-yon yozib, shu ketma-ketlikda o'qiydi.

Ko'rayapsizmi, yechimlar har doim ham murakkab bo'lishi shart emas. Shunchaki asl muammoni chuqurroq o'rganish va ozgina kreativ fikrlash chiroyli yechimlarga olib keladi (afsuski, har doim ham emas).

Ko'pchilik DBMSlar client-server (server bu yerda database) communication uchun alohida protocollar ishlab chiqqan.
Ya'ni networking uchun ularning alohida protocoli bor.
E'tiborli jihati, ko'p DBMSlarda bu communication davomida va ayniqsa connection ochish vaqtida juda ko'p metadata almashiladi (o'zim PostgreSQL va MongoDBda kuzatdim).

Bu databaselar bilan ishlayotganda connection ochish ancha "qimmat"ga tushadi degani. Bitta connectionni uzoqroq ishlating (albatta, butunligiga ishonch hosil qilib) yoki connection pool ishlating.

P.S. Har bitta query uchun alohida connection ochadigan tanishlarga yuboramiz ))
P.S.2. PHPchilarga yuboramiz ))

"Sifatli softwarega kuchli toollar orqali emas, kuchli dasturchilar orqali erishiladi." – degandi David West.
Bu degani tool qanchalik zo'r bo'lmasin, u to'g'ri ishlatilmasa "bir tiyinga qimmat".

Masalan, GraphQL hozir ancha mashhur bo'lib ketdi. Xo'sh savol, uning RESTdan eng ustun tomoni nima? Flexibility!
Facebookdagilar aynan shuning uchun GraphQLni yaratgan. Clientda RESTdagiga o'xshab o'ziga kerakli 2-3 ta fieldni olish uchun butun boshli ulkan obyektni emas, faqat o'zi so'ragan, o'zi uchun yetarli minimal datani olish imkoniyati bor. Bu aslidan minglab marta sodda ko'rinishdagi tushuntirish.

Xo'sh, buni texnologiyani noto'g'ri ishlatayotganlar ham bormi?
Ochig'ini aytganda, faqat sanoqli kompaniyalargina to'g'ri ishlata olayapti. Men siz yaqinda ishlab chiqqan CRM yoki lokal bank tizimi haqida gapirmayapman. Hattoki Twitterga o'xshash kuchli mutaxassislarga ega texnogigantlar ham implementatsiyaga kelganda oqsoqlanayapti. Ishonmaysizmi? Twitterning web versiyasini inspect qilib, network panelni kuzating, o'zingiz ko'rasiz.

Qisqasi, Python PHPdan zo'r deyishdan oldin post boshidagi gapni o'qing.

P.S. "Sen kim bo'libsan Twitterning ogorodiga tosh otadigan?" deydiganlarga javob – mashinaga baho berish uchun oldin o'zingiz mashina qurishingiz shart emas (ayniqsa bizda).

"Hozircha ishlaydigan" yechim qilmang.
Sizdan keyin ishlaydiganlarga rahmingiz kelsin...

Testing is not over-engineering.
AUF☝️

P.S. Change my mind.

1990-yillar, internetni faqat ma'lum tashkilotlar orasidagina emas, butun dunyo bo'ylab ishlatish g'oyasi bilan chiqqan WWW endi tug'ilgan vaqtlar. IP, TCP, OSI kabi internetning "building block"lari allaqachon ishlab chiqilgan, lekin WWW uchun standartlar kerak edi. Ma'lumotni foydalanuvchiga yetkazish tili sifatida HTML ishlab chiqildi (va bu tildagi ma'lumotni render qilib, UIda ko'rsatish uchun browser ishlab chiqildi).
Networking uchun TCP va UDP kabi transport layer protocollar ishlab chiqilgan bo'lsa ham, tez, yengil, ishonchli va asosiysi, application layerda ishlaydigan protocol ishlab chiqishga ehtiyoj tug'ildi.

Shunday qilib HTTP ishlab chiqildi. Dastlabki versiya o'ta sodda va imkoniyatlari kam edi. Path orqali murojaat qilib, serverda turgan faylni yuklab olish mumkin edi xolos (faqatgina GET methodi bor edi). Keyinchalik bu versiyani boshqalardan farqlash uchun HTTP/0.9 deb nomlandi.

Keyingi versiyalarga to'xtishdan oldin HTTPning o'zi haqida biroz:
HTTP application layerda ishlaydigan, TCP protocoli ustiga qurilgan (h3 gacha), client-server modelini support qiladigan stateless protocol.
Nega stateless? Sababi protocol yengil va tez bo'lishi kerak edi. Stateful bo'lish esa protocolni og'irlashtirish va sekinlashtirishga olib keladi. Qiziq, unda nega stateful network protocol (TCP)ning ustiga qurildi? Sababi, protocol ishonchli bo'lishi kerak edi. TCP state orqali data to'liq yetkazilishini ta'minlaydi. Davom etamiz.

Tim Berners-Lee va uning jamoasining ko'p mehnatlaridan so'ng va nihoyat 1996-yil HTTP/1.0 rasman standart bo'ldi va RFC 1945 sifatida kiritildi.
Xo'sh bu versiyaga asosan nimalar kiritildi?
1. Status kodlari. Bu orqali browser request success bo'lgan yoki bo'lmaganini aniqlash imkoni tug'ildi.
2. POST va HEAD methodlari.
3. Request headerlar. Bu juda ko'plab yangi imkoniyatlar eshigini ochdi, masalan, hypertextdan boshqa content typelar bilan ishlash).
Jamoa esa tajriba qilishda davom etdi.

1 yildan keyinoq HTTP/1.1 ishlab chiqildi va RFC 2068 sifatida taqdim etildi. O'zgarishlar:
1. Bitta TCP connectionni keyingi request uchun qayta ishlatish imkoniyati. Sababi, TCP connection ochish ancha "qimmat"ha tushadi va bitta connectionni uzoqroq ishlatish kerak.
2. Yangi request methodlari.
3. Content haqida ko'proq metadata.
4. Katta hajmli responseni bo'laklab yuborish imkoniyati.
Keyingi yillar davomida WWW ancha takomillashdi, protocolga qo'yilgan talablar oshdi va natijada HTTPga yana ko'plab o'zgarishlar qo'shib borildi. Bir muammo borgan sari jiddiylashib bordi: bir nechta request yuborish uchun avvalgi requestga response kelishini kutib, undan keyingina keyingi requestni yuborish mumkin edi. Natijada client resurslarni olish uchun juda ko'p vaqt sarflashga majbur edi. Buni hal qilish uchun bir vaqtning o'zida 6 tagacha parallel connection ochib, request yuborish imkoniyati qo'shildi. Bu HTTP/1.1 ning 1.0 ga qaraganda eng ustun jihatlaridan biri bo'ldi. TLSni support qilish orqali protocol HTTPS deb atala boshlandi va shunga o'xshash bir nechta juda muhim yangilanishlar bo'ldi. 1.1 juda omadli chiqdi: tez, yengil va muhimi, moslashuvchan. Lekin shu bilan birga ba'zi jiddiy muammolari ham bor edi...

2015-yil, 1.1 versiya yaratilganidan 18 yil o'tib avvalgisidan ancha farq qiladigan zamonaviy protocol – HTTP/2 ishlab chiqildi (RFC 7540).
1.1 ko'plab requestlarni 6 ta parallel connection orqali hal qilgandi, lekin bu endi ancha samarasiz bo'lib qoldi. H2 da bu juda chiroyli usulda yechildi: bitta TCP connectionda bir vaqtda ko'plab request yuborish imkoniyati (bu narsa multiplexing deyiladi) bor va muhimi avvalgi requestga response kelishini kutib o'tirish shart emas! Shunchaki o'nlab request yuborasiz va server birin-ketin javob beraveradi. Responselar aralashib ketmasligi uchun har bir requestga ma'lum ID beriladi va server shu ID bilan response qaytaradi. Ha, bu "game changer" feature bo'ldi. Bundan tashqari juda ko'plab o'zgarishlar bor, qolganini o'zingiz topib o'qiysiz.

@boboshersnotes

HTTP/3 yoki xayr TCP.
Request multiplexing juda ajoyib yechim edi, faqat bitta jiddiy muammosi bor ekan. TCP stateful protocol va uni agar dataning bir qismi yetib kelmasa, ma'lum vaqtdan keyin qayta uzatiladi va bu oraliqda yetib kelgan ma'lumot ham bloklanib turadi. Bu narsa OSIda 4-qavatda sodir bo'ladi, HTTP esa 7-qavatda. Demak, biz yuborgan 10 ta HTTP request TCP uchun shunchaki bir butun data, u request nimaligini ham bilmaydi. Natijada o'sha 10 ta requestdan birortasi qisman yetib kelmasa ham TCP hamma requestlarni bloklaydi. Bu HOL blocking deyiladi.
Bu muammoni hal qilish uchun h3 (RFC 9114) TCPdan voz kechib, UDP ustiga qurilgan QUIC protocolidan foydalanadi. UDPning o'zida retransmission yo'q. QUIC bu narsani o'zi ishlab chiqdi va buning TCPdagi retransmissiondan farqli jihati, QUIC bitta connection ichidagi HTTP requestlarni bir-biridan ajrata oladi. Sababi, QUICning o'zida multiplexing xususiyati bor va u retransmission bilan bitta layerda joylashgan. Natijada request to'liq yetib kelmasa butun boshli connection emas, faqat o'sha request bloklanadi.

Xo'sh, shu bilan muammolar tugadimi? Albatta yo'q. Muammolarni yechishda davom etamiz...
Bu maqolani yozishdan maqsad HTTPning evolutsiyasi haqida qisqacha ma'lumot berish va sizni bu borada yana izlanishga undash. Xato va kamchiliklarni aytib, feedback qoldirsangiz, xursand bo'laman.

Foydalanilgan manbaalar:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
https://en.m.wikipedia.org/wiki/Hypertext_Transfer_Protocol
https://datatracker.ietf.org

P.S. Tanishlarga share qilinoradi 🙂

@boboshersnotes

DB haqidagi postga comment:
— Backend engineer databaseni yaxshi bilishi qanchalik muhim?
Networking haqidagi postga comment:
— Bularni backend developer bilishi shartmi?
Languagening ichki komponentlari haqidagi postdan keyin:
— Bu ancha chuqur narsalar, bu backendchilarga kerakmi?
System design haqidagi postdan keyin:
— Bu savollar intervyularda so'raladimi?
...

O'rtog'lar, bular kerak bo'lmasa backend engineerning vazifasi nima o'zi?😅

"A Philosophy of Software Design" kitobi muallifi, Stanford universiteti professori John Ousterhout TCP datacenterlarda ishlatish uchun ancha noqulay, Homa protocolga o'tish kerak deb hisoblayapti.
E'tiborimni tortgan jihati, paperda TCPning faqat negativ tomonlari, Homaning faqat pozitiv tomonlariga urg'u berilgan. Balki menga shunday tuyuldi.

Qiziq, kompaniyalar rostdan ham datacenterlardagi communicationni Homaga o'tkazishga qaror qilsa kim birinchi bo'larkin?

Multithreading is just async, but implemented on a lower level.
Change my mind.

P.S. Discussion ochiq deb e'lon qilaman ))

Xususiy bankdan $1.5M o'g'irlandi va bu katta ehtimol bilan bizning sohamizdagilarning xatosi bilan sodir bo'ldi. Bu qolganlarga dars bo'lishi kerak.
Biz esa hamma kanalda anavi .NETchi yigitni muhokama qilayapmiz.

Nagle's algorithm + delayed acknowledgment = ❤️

Rostini aytganda, bu hazil edi (faqat biroz intellektual). "😁" emoji bosganlarning hammasi hazilni tushungan deb umid qilaman. JR aytganidek, endi postlarimga bunisi hazil, bunisi rost deb qo'shib ketaman.

***

Endi postning o'zi haqida.

Nagle's algorithm, TCP delayed ACK, bir-biridan vahimali nomlar juda murakkab tuyulayaptimi? Keling odam tushunadigan tilda gaplashamiz.

Tasavvur qiling 25 ta kursdosh Samarqandga taksida bormoqchisizlar. 6 ta taksiga 4 kishidan 24 kishi yo'lga chiqib ketdi, lekin yana bir kishi qoldi. U o'zi bitta taksiga chiqdi, lekin taksist hali haydamaydi. Nega? Sababi, u hali "to'lmadi". Yana 3 ta odam olsa, keyin yuradi. Faqat 1 kishi bilan haydash o'ziga qimmatga tushadi (metan qimmat). Oddiy mantiq. Xuddi shu narsaning network engineeringdagi nomi Nagle's algorithm deyiladi. Taksi bu TCP segment, talabalar - yuborilayotgan ma'lumot. Oxirgi, to'lmay qolgan segmentga yana data kelmagunicha yoki oldinroq yuborilgan segmentlar uchun ACK kelmagunicha (sheriklari biz Samarqandga yetib keldik demagunicha).
Foydali tomoni - resurslar tejaladi. Zararli tomoni - "kimdir" kech qoladi.

Delayed ACK esa xuddi shu voqeaning davomi, faqat Samarqandda.
Studentlar yetib borganidan keyin yetib keldim deb qolganlarga xabar berishi kerak, lekin xabar berish juda qimmat turadi, studentlar esa tejamkor.
Shunda bittasining aqli ishlab qoladi: hamma alohida-alohida telefon qilmaydi, bir kishi telefon qilib hamma kelganlarni aytib chiqadi (Karl, bizning studentlar tejash uchun nimalarni o'ylab topmagan). Lekin u qachon telefon qiladi? Endi telefonni o'chirganida yana bir kishi yetib kelsa u uchun yana alohida telefon qilish kerakku? Oddiy, yana yarim soat (bu bir misol uchun) kutamiz, hech kim kelmasa telefon qilamiz. Xuddi shu narsa networkingda TCP delayed ACK deyiladi. Studentlar segmentda yetib kelgan ma'lumot, telefon esa server tomonidan segment yetib kelgani haqida yuboriladigan ACK signali.
Foydali tomoni - resurslarni tejaydi. Zararli tomoni - "narigi taraf" segment yetib kelganini kechroq biladi.

Xo'sh, endi qiziq joyi: agar tepadagi ikkita holat bir vaqtda bo'lsa nima bo'ladi.
1 ta student haliyam taksida kutib o'tiribdi. Ketish uchun yo taksi to'lishi kerak, yo yetib borgan sheriklari telefon qilishi kerak. Aksiga olib, boshqa ketadigan odam yo'q, endi sheriklarni kutish kerak. Lekin sheriklar nega telefon qilmayapti? Qizig'i, Samarqandda sheriklari telefon qilmay, hozir sherigimiz kelsa hammamiz bittada telefon qilamiz deb buni kutib o'tiribdi. Bu taksida qolganlarni kutib o'tiribdi, qolganlar Samarqandda buni kutib o'tiribdi, bu nimanidir eslatmayaptimi? DEAD LOCK! Faqat farqi, Samarqanddagilar oxiri sabri tugab, "shuncha kutdik, kelmasang ayb bizdamas" deb telefon qiladi. Taksida o'tirgan talaba buni ko'rib, "4 kishiga to'layman, haydang" deb bir o'zi bitta taksida ketadi. Muammo hal bo'ldi, lekin juda ko'p vaqt bekorchi o'tib ketdi.

Xuddi shu narsa network engineeringda ham bo'lib turadi. Bu tarafda sender segment to'lishini kutadi, narigi tarafda reciever ACK yubormasdan qolgan segment kelishini kutadi, natijada connection UZOQ VAQT "qotib" qoladi.

P.S. Tepadagi postning ma'nosini tushungan bo'lsangiz, endi kulavering ))

Postdan olingan 2 ta xulosa:
1. Taksistlar siyosat tugul dasturlashni ham "qoyillatib" qo'yadi.
2. Talabalar pul tejash uchun har baloni o'ylab topadi.