Golang

Dacă vin 1000 de cereri simultane, vor fi create 1000 de fire de sistem de operare? Ce se va întâmpla cu serviciul în acest caz?

Există o fațadă care agregă date din 10 servicii, fiecare răspunde în 100 ms, totalizând aproximativ o secundă. Cum ai rezolva această problemă pentru ca endpoint-ul să returneze datele mai rapid?

Ai continua să mergi la celelalte servicii pentru date dacă primul dintre cele 11 servicii returnează o eroare?

După ce principiu ați ales arhitectura și limitele serviciilor?

Cum să rezolvi problema de data race despre care am vorbit?

Redis era în toate cele trei centre de date?

Aveai trei centre de date — cum a fost organizat schema de replicare/rezerve între ele?

Sau Redis era într-un singur centru de date, și toți se conectau la el?

Centrele de date erau copii complete între ele sau se completau? Pur și simplu rutai traficul între ele?

La ce câmp de blocare te referi (lămurire despre denormalizare, steagul is_blocked)?

Care pot fi efectele secundare ale utilizării goroutine-urilor pentru procesarea unui fișier, la ce trebuie să fim pregătiți?

Și dacă goroutine-urile vor scrie în aceeași linie/buffer, este posibilă o astfel de problemă?

Evenimentul ajunge în primul centru de date din Kafka, îl capturăm și îl stocăm în Redis. Cum au ajuns aceste date în toate cele trei centre de date?

Cum pot goroutine-urile să «scape» (scurgă)?

Ai scris în CV-ul tău că ai optimizat interogările SQL. Cum crezi că ar arăta planul de execuție pentru o interogare care selectează vânzători neblocați (EXPLAIN)?

Există alte modalități, în afară de canale, de a organiza munca cu goroutines?

CV-ul tău indică 50-80 de mii RPS. Ce fel de serviciu era și ce făcea?

Poți vorbi despre algoritmul de audit (verificarea datelor)? Ai participat la el? Cum s-a desfășurat?

Ai vorbit despre modelul de citire cu Redis. Redis a fost replicat între centrele de date?

Cum ai obține, cu o singură interogare, lista vânzătorilor neblocați, având o tabelă cu toți vânzătorii și alta doar cu vânzători blocați?