Web Analytics

system-design-primer

⭐ 318813 stars Italian by donnemartin

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

Aiuta a tradurre questa guida!

The System Design Primer


Motivazione

Impara a progettare sistemi su larga scala.
>
Preparati per il colloquio di system design.

Impara a progettare sistemi su larga scala

Imparare a progettare sistemi scalabili ti aiuterà a diventare un ingegnere migliore.

La progettazione dei sistemi è un argomento ampio. Ci sono numerose risorse sparse sul web riguardanti i principi di progettazione dei sistemi.

Questa repository è una raccolta organizzata di risorse per aiutarti a imparare come costruire sistemi su larga scala.

Impara dalla comunità open source

Questo è un progetto open source continuamente aggiornato.

Contributi sono benvenuti!

Preparati per il colloquio di system design

Oltre ai colloqui di coding, il system design è una componente obbligatoria del processo di colloquio tecnico in molte aziende tecnologiche.

Esercitati con le domande comuni dei colloqui di system design e confronta i tuoi risultati con soluzioni di esempio: discussioni, codice e diagrammi.

Argomenti aggiuntivi per prepararti al colloquio:

Flashcard Anki


I mazzi di flashcard Anki forniti utilizzano la ripetizione dilazionata per aiutarti a memorizzare i concetti chiave di progettazione dei sistemi.

Ottimo per l'uso in mobilità.

Risorsa di programmazione: Sfide di programmazione interattive

Cerchi risorse per prepararti al Colloquio di programmazione?


Dai un'occhiata al repository gemello Interactive Coding Challenges, che contiene un ulteriore mazzo Anki:

Contribuire

Impara dalla community.

Sentiti libero di inviare pull request per aiutare a:

I contenuti che necessitano di revisione sono posti in sviluppo.

Consulta le Linee guida per i contributi.

Indice degli argomenti di system design

Sommari di vari argomenti di system design, inclusi pro e contro. Tutto è un compromesso.
>
Ogni sezione contiene link a risorse più approfondite.


Guida allo studio

Argomenti suggeriti da rivedere in base alla tempistica del tuo colloquio (breve, media, lunga).

Imgur

D: Per i colloqui, devo conoscere tutto ciò che è qui?

R: No, non è necessario conoscere tutto ciò che è qui per prepararsi al colloquio.

Le domande che ti vengono poste in un colloquio dipendono da variabili come:

Generalmente si prevede che i candidati più esperti conoscano di più sulla progettazione dei sistemi. Gli architetti o i team lead potrebbero dover sapere più degli individual contributor. Le migliori aziende tecnologiche potrebbero avere uno o più round di colloqui sulla progettazione.

Inizia in modo ampio e approfondisci in alcune aree. È utile conoscere almeno un po’ i vari temi chiave della progettazione dei sistemi. Adatta la guida seguente in base alla tua tempistica, esperienza, alle posizioni per cui stai facendo colloqui e alle aziende con cui ti stai candidando.

| | Breve | Media | Lunga | |---|---|---|---| | Leggi i Temi di progettazione dei sistemi per ottenere una comprensione generale di come funzionano i sistemi | :+1: | :+1: | :+1: | | Leggi alcuni articoli nei Blog di ingegneria delle aziende delle aziende per cui ti candidi | :+1: | :+1: | :+1: | | Leggi alcune Architetture reali | :+1: | :+1: | :+1: | | Rivedi Come affrontare una domanda di colloquio di progettazione di sistemi | :+1: | :+1: | :+1: | | Lavora su Domande di colloquio di progettazione di sistemi con soluzioni | Alcune | Molte | La maggior parte | | Lavora su Domande di colloquio di progettazione orientata agli oggetti con soluzioni | Alcune | Molte | La maggior parte | | Rivedi Domande aggiuntive di colloquio di progettazione di sistemi | Alcune | Molte | La maggior parte |

Come affrontare una domanda di colloquio di progettazione di sistemi

Come gestire una domanda di colloquio sulla progettazione di sistemi.

Il colloquio di progettazione di sistemi è una conversazione aperta. Ci si aspetta che tu la conduca.

Puoi utilizzare i seguenti passaggi per guidare la discussione. Per aiutarti a consolidare questo processo, lavora sulle Domande di colloquio di progettazione di sistemi con soluzioni seguendo i passaggi seguenti.

Passaggio 1: Definisci casi d’uso, vincoli e assunzioni

Raccogli i requisiti e delimita il problema. Fai domande per chiarire i casi d’uso e i vincoli. Discuti le assunzioni.

Passaggio 2: Crea un design ad alto livello

Definisci un design ad alto livello con tutti i componenti importanti.

Step 3: Progettazione dei componenti principali

Approfondisci i dettagli di ciascun componente principale. Ad esempio, se ti venisse chiesto di progettare un servizio di abbreviazione URL, discuti:

Step 4: Scala il design

Identifica e affronta i colli di bottiglia, dati i vincoli. Ad esempio, hai bisogno di quanto segue per affrontare problemi di scalabilità?

Discuti le possibili soluzioni e i compromessi. Tutto è un compromesso. Affronta i colli di bottiglia usando i principi di progettazione scalabile dei sistemi.

Calcoli approssimativi

Potresti essere invitato a fare alcune stime manuali. Consulta l’Appendice per le seguenti risorse:

Fonte/i e ulteriori letture

Consulta i seguenti link per avere un’idea più chiara di cosa aspettarti:

Domande di colloquio di progettazione di sistemi con soluzioni

Domande comuni di colloquio di progettazione di sistemi con discussioni, codice e diagrammi di esempio.
>
Soluzioni collegate ai contenuti nella cartella solutions/.

| Domanda | | |---|---| | Progettare Pastebin.com (o Bit.ly) | Soluzione | | Progettare la timeline e la ricerca di Twitter (o feed e ricerca di Facebook) | Soluzione | | Progettare un web crawler | Soluzione | | Progettare Mint.com | Soluzione | | Progettare le strutture dati per un social network | Soluzione | | Progettare un archivio chiave-valore per un motore di ricerca | Soluzione | | Progettare la funzione di ranking delle vendite per categoria di Amazon | Soluzione | | Progettare un sistema che scala a milioni di utenti su AWS | Soluzione | | Aggiungi una domanda di progettazione di sistemi | Contribuisci |

Progettare Pastebin.com (o Bit.ly)

Visualizza esercizio e soluzione

Imgur

Progettare la timeline e la ricerca di Twitter (o feed e ricerca di Facebook)

Visualizza esercizio e soluzione

Imgur

Progettare un web crawler

Visualizza esercizio e soluzione

Imgur

Design Mint.com

View exercise and solution

Imgur

Design the data structures for a social network

View exercise and solution

Imgur

Design a key-value store for a search engine

View exercise and solution

Imgur

Design Amazon's sales ranking by category feature

View exercise and solution

Imgur

Design a system that scales to millions of users on AWS

View exercise and solution

Imgur

Object-oriented design interview questions with solutions

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

>Note: This section is under development

| Question | | |---|---| | Progetta una hash map | Soluzione | | Progetta una cache least recently used | Soluzione | | Progetta un call center | Soluzione | | Progetta un mazzo di carte | Soluzione | | Progetta un parcheggio | Soluzione | | Progetta un server di chat | Soluzione | | Progetta un array circolare | Contribuisci | | Aggiungi una domanda di progettazione orientata agli oggetti | Contribuisci |

Argomenti di system design: inizia qui

Nuovo alla progettazione di sistemi?

Per prima cosa, avrai bisogno di una comprensione di base dei principi comuni, imparando cosa sono, come vengono utilizzati e i loro pro e contro.

Passo 1: Rivedi la video-lezione sulla scalabilità

Lezione sulla Scalabilità ad Harvard

Passo 2: Rivedi l'articolo sulla scalabilità

Scalabilità

Prossimi passi

Successivamente, esamineremo i compromessi di alto livello:

Ricorda che tutto è un compromesso.

Poi approfondiremo argomenti più specifici come DNS, CDN e bilanciatori di carico.

Prestazioni vs scalabilità

Un servizio è scalabile se porta a un aumento delle prestazioni in modo proporzionale alle risorse aggiunte. In generale, aumentare le prestazioni significa servire più unità di lavoro, ma può anche significare gestire unità di lavoro più grandi, come quando i dataset crescono.1

Un altro modo di vedere prestazioni vs scalabilità:

Fonte(i) e ulteriori letture

Latenza vs throughput

Latenza è il tempo necessario per eseguire un'azione o produrre un risultato.

Throughput è il numero di tali azioni o risultati per unità di tempo.

In generale, dovresti puntare a massimizzare il throughput con latenza accettabile.

Fonte(i) e ulteriori letture

Disponibilità vs coerenza

Teorema CAP


Fonte: CAP theorem revisited

In un sistema informatico distribuito, puoi supportare solo due delle seguenti garanzie:

Le reti non sono affidabili, quindi dovrai supportare la tolleranza alle partizioni. Sarà necessario fare un compromesso software tra consistenza e disponibilità.

#### CP - consistenza e tolleranza alle partizioni

Attendere una risposta dal nodo partizionato potrebbe causare un errore di timeout. CP è una buona scelta se le esigenze aziendali richiedono letture e scritture atomiche.

#### AP - disponibilità e tolleranza alle partizioni

Le risposte restituiscono la versione più facilmente disponibile dei dati su qualsiasi nodo, che potrebbe non essere la più recente. Le scritture potrebbero impiegare del tempo per propagarsi quando la partizione viene risolta.

AP è una buona scelta se le esigenze aziendali consentono consistenza eventuale o quando il sistema deve continuare a funzionare nonostante errori esterni.

Fonte/i e ulteriori letture

Pattern di consistenza

Con più copie degli stessi dati, ci troviamo di fronte a diverse opzioni su come sincronizzarle affinché i client abbiano una visione coerente dei dati. Ricorda la definizione di consistenza dal teorema CAP - Ogni lettura riceve la scrittura più recente o un errore.

Consistenza debole

Dopo una scrittura, le letture potrebbero vederla o meno. Si adotta un approccio best effort.

Questo approccio si osserva in sistemi come memcached. La consistenza debole funziona bene in casi d'uso in tempo reale come VoIP, video chat e giochi multiplayer in tempo reale. Ad esempio, se sei al telefono e perdi la ricezione per alcuni secondi, quando riacquisti la connessione non senti ciò che è stato detto durante la perdita di connessione.

Consistenza eventuale

Dopo una scrittura, le letture la vedranno eventualmente (tipicamente entro millisecondi). I dati sono replicati in modo asincrono.

Questo approccio si trova in sistemi come DNS ed email. La consistenza eventuale funziona bene nei sistemi altamente disponibili.

Consistenza forte

Dopo una scrittura, le letture la vedranno. I dati sono replicati in modo sincrono.

Questo approccio si trova nei file system e nei RDBMS. La consistenza forte funziona bene nei sistemi che necessitano di transazioni.

Fonte/i e ulteriori letture

Pattern di disponibilità

Ci sono due pattern complementari per supportare un’elevata disponibilità: fail-over e replicazione.

Fail-over

#### Attivo-passivo

Con il fail-over attivo-passivo, vengono inviati heartbeat tra il server attivo e quello passivo in standby. Se l’heartbeat viene interrotto, il server passivo assume l’indirizzo IP dell’attivo e riprende il servizio.

La durata del downtime è determinata dal fatto che il server passivo sia già in standby “hot” o se debba avviarsi da standby “cold”. Solo il server attivo gestisce il traffico.

Il failover attivo-passivo può essere chiamato anche failover master-slave.

#### Attivo-attivo

Nell’attivo-attivo, entrambi i server gestiscono il traffico, distribuendo il carico tra loro.

Se i server sono pubblici, il DNS deve conoscere gli IP pubblici di entrambi i server. Se i server sono interni, la logica applicativa deve conoscere entrambi i server.

Il failover attivo-attivo può essere chiamato anche failover master-master.

Svantaggio/i: failover

Replicazione

#### Master-slave e master-master

Questo argomento è ulteriormente trattato nella sezione Database:

Disponibilità in numeri

La disponibilità è spesso quantificata dal tempo di attività (o inattività) come percentuale del tempo in cui il servizio è disponibile. La disponibilità viene generalmente misurata in numero di 9--un servizio con il 99,99% di disponibilità viene descritto come avente quattro 9.

#### 99,9% di disponibilità - tre 9

| Durata | Tempo di inattività accettabile| |---------------------|-------------------------------| | Inattività per anno | 8h 45min 57s | | Inattività per mese | 43m 49,7s | | Inattività per settimana | 10m 4,8s | | Inattività per giorno| 1m 26,4s |

#### 99,99% di disponibilità - quattro 9

| Durata | Tempo di inattività accettabile| |---------------------|-------------------------------| | Inattività per anno | 52min 35,7s | | Inattività per mese | 4m 23s | | Inattività per settimana | 1m 5s | | Inattività per giorno| 8,6s |

#### Disponibilità in parallelo vs in sequenza

Se un servizio è composto da più componenti soggetti a guasti, la disponibilità complessiva del servizio dipende dal fatto che i componenti siano in sequenza o in parallelo.

###### In sequenza

La disponibilità complessiva diminuisce quando due componenti con disponibilità < 100% sono in sequenza:

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

Se sia Foo che Bar avessero ciascuno una disponibilità del 99,9%, la loro disponibilità totale in sequenza sarebbe del 99,8%.

###### In parallelo

La disponibilità complessiva aumenta quando due componenti con disponibilità < 100% sono in parallelo:

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

Se sia Foo che Bar avessero ciascuno una disponibilità del 99,9%, la loro disponibilità totale in parallelo sarebbe del 99,9999%.

Sistema dei nomi di dominio


Fonte: Presentazione sulla sicurezza DNS

Un Sistema dei Nomi di Dominio (DNS) traduce un nome di dominio come www.example.com in un indirizzo IP.

Il DNS è gerarchico, con pochi server autorevoli al livello superiore. Il tuo router o ISP fornisce informazioni su quale(i) server DNS contattare durante una ricerca. I server DNS di livello inferiore memorizzano nella cache le mappature, che potrebbero diventare obsolete a causa dei ritardi di propagazione DNS. I risultati DNS possono essere memorizzati nella cache anche dal browser o dal sistema operativo per un certo periodo di tempo, determinato dal time to live (TTL).

Servizi come CloudFlare e Route 53 offrono servizi DNS gestiti. Alcuni servizi DNS possono instradare il traffico tramite vari metodi:

Svantaggio(i): DNS

Fonte(i) e ulteriori letture

Content delivery network


Fonte: Perché usare una CDN

Una content delivery network (CDN) è una rete globale distribuita di server proxy, che fornisce contenuti da posizioni più vicine all'utente. Generalmente, file statici come HTML/CSS/JS, foto e video sono serviti da una CDN, anche se alcune CDN come CloudFront di Amazon supportano contenuti dinamici. La risoluzione DNS del sito indicherà ai client quale server contattare.

Fornire contenuti tramite CDN può migliorare significativamente le prestazioni in due modi:

Push CDN

Le push CDN ricevono nuovi contenuti ogni volta che si verificano cambiamenti sul tuo server. Sei completamente responsabile della fornitura dei contenuti, caricandoli direttamente sulla CDN e riscrivendo gli URL per puntare alla CDN. Puoi configurare quando i contenuti scadono e quando vengono aggiornati. I contenuti vengono caricati solo quando sono nuovi o modificati, minimizzando il traffico ma massimizzando lo storage.

I siti con poco traffico o con contenuti che non vengono aggiornati spesso funzionano bene con le push CDN. I contenuti vengono caricati sulle CDN una sola volta, invece di essere ripresi regolarmente.

Pull CDN

Le pull CDN prelevano nuovi contenuti dal tuo server quando il primo utente li richiede. Lasci i contenuti sul tuo server e riscrivi gli URL per puntare alla CDN. Questo comporta una richiesta più lenta fino a quando il contenuto non viene memorizzato nella cache sulla CDN.

Un time-to-live (TTL) determina per quanto tempo i contenuti vengono mantenuti in cache. Le pull CDN minimizzano lo spazio di archiviazione sulla CDN, ma possono creare traffico ridondante se i file scadono e vengono ripresi prima che siano effettivamente cambiati.

I siti con molto traffico funzionano bene con le pull CDN, poiché il traffico viene distribuito più uniformemente e solo i contenuti richiesti di recente rimangono sulla CDN.

Svantaggio(i): CDN

Fonte(i) e approfondimenti

Bilanciatore di carico


Fonte: Scalable system design patterns

I bilanciatori di carico distribuiscono le richieste dei client in arrivo alle risorse di calcolo come server applicativi e database. In ogni caso, il bilanciatore di carico restituisce la risposta dalla risorsa di calcolo al client appropriato. I bilanciatori di carico sono efficaci per:

I bilanciatori di carico possono essere implementati con hardware (costoso) o con software come HAProxy.

Ulteriori vantaggi includono:

Per proteggersi dai guasti, è comune configurare più bilanciatori di carico, sia in modalità attivo-passivo che attivo-attivo.

I bilanciatori di carico possono instradare il traffico in base a vari parametri, tra cui:

Bilanciamento del carico Layer 4

I bilanciatori di carico Layer 4 osservano le informazioni al livello di trasporto per decidere come distribuire le richieste. Generalmente, questo implica gli indirizzi IP di origine e destinazione e le porte nell’intestazione, ma non il contenuto del pacchetto. I bilanciatori di carico Layer 4 inoltrano i pacchetti di rete da e verso il server upstream, effettuando il Network Address Translation (NAT).

Bilanciamento del carico Layer 7

I bilanciatori di carico Layer 7 esaminano il livello applicativo per decidere come distribuire le richieste. Questo può coinvolgere il contenuto dell’header, del messaggio e dei cookie. I bilanciatori di carico Layer 7 terminano il traffico di rete, leggono il messaggio, prendono una decisione di bilanciamento del carico, quindi aprono una connessione al server selezionato. Ad esempio, un bilanciatore di carico Layer 7 può indirizzare il traffico video ai server che ospitano i video mentre indirizza il traffico di fatturazione utente più sensibile a server rinforzati per la sicurezza.

Al costo della flessibilità, il bilanciamento del carico Layer 4 richiede meno tempo e risorse di calcolo rispetto al Layer 7, anche se l’impatto sulle prestazioni può essere minimo sull’hardware moderno di tipo commerciale.

Scalabilità orizzontale

I bilanciatori di carico possono anche aiutare con la scalabilità orizzontale, migliorando prestazioni e disponibilità. L’ampliamento tramite macchine commerciali è più conveniente e garantisce una maggiore disponibilità rispetto all’ampliamento di un singolo server su hardware più costoso, chiamato Scalabilità Verticale. È anche più facile assumere personale che lavori su hardware commerciale rispetto a sistemi aziendali specializzati.

#### Svantaggio(i): scalabilità orizzontale

Svantaggio(i): bilanciatore di carico

Fonte(i) e approfondimenti

Reverse proxy (server web)


Fonte: Wikipedia

Un reverse proxy è un server web che centralizza i servizi interni e fornisce interfacce unificate al pubblico. Le richieste dei client vengono inoltrate a un server che può soddisfarle, prima che il reverse proxy restituisca la risposta del server al client.

Ulteriori vantaggi includono:

Bilanciatore di carico vs reverse proxy

Svantaggio(i): reverse proxy

Fonte(i) e ulteriori letture

Livello applicazione


Fonte: Introduzione all'architettura di sistemi scalabili

Separare il livello web dal livello applicativo (noto anche come livello piattaforma) permette di scalare e configurare entrambi i livelli in modo indipendente. Aggiungere una nuova API comporta l'aggiunta di server applicativi senza necessariamente aggiungere ulteriori server web. Il principio della singola responsabilità sostiene servizi piccoli e autonomi che collaborano tra loro. Piccoli team con piccoli servizi possono pianificare più aggressivamente una crescita rapida.

I worker nel livello applicativo aiutano anche ad abilitare l'asincronismo.

Microservizi

Riguardo questa discussione ci sono i microservizi, che possono essere descritti come un insieme di servizi piccoli, modulari e distribuibili in modo indipendente. Ogni servizio esegue un processo unico e comunica tramite un meccanismo ben definito e leggero per raggiungere un obiettivo aziendale. 1

Pinterest, ad esempio, potrebbe avere i seguenti microservizi: profilo utente, follower, feed, ricerca, caricamento foto, ecc.

Service Discovery

Sistemi come Consul, Etcd, e Zookeeper aiutano i servizi a trovarsi tra loro tenendo traccia di nomi registrati, indirizzi e porte. I controlli di integrità aiutano a verificare l'integrità del servizio e sono spesso eseguiti tramite un endpoint HTTP. Sia Consul che Etcd hanno un key-value store integrato che può essere utile per memorizzare valori di configurazione e altri dati condivisi.

Svantaggi: livello applicativo

Fonte(e) e approfondimenti

Database


Fonte: Scalare fino ai tuoi primi 10 milioni di utenti

Sistema di gestione di database relazionali (RDBMS)

Un database relazionale come SQL è una raccolta di elementi di dati organizzati in tabelle.

ACID è un insieme di proprietà delle transazioni dei database relazionali.

Esistono molte tecniche per scalare un database relazionale: replicazione master-slave, replicazione master-master, federazione, sharding, denormalizzazione e ottimizzazione SQL.

#### Replicazione master-slave

Il master gestisce le letture e le scritture, replicando le scritture su uno o più slave, che gestiscono solo le letture. Gli slave possono anche replicare su altri slave in modo gerarchico. Se il master va offline, il sistema può continuare a funzionare in modalità sola lettura fino a quando uno slave viene promosso a master o viene predisposto un nuovo master.


Fonte: Scalabilità, disponibilità, stabilità, pattern

##### Svantaggio/i: replicazione master-slave

#### Replicazione master-master

Entrambi i master gestiscono letture e scritture e si coordinano tra loro sulle scritture. Se uno dei master si guasta, il sistema può continuare a funzionare sia per le letture che per le scritture.


Fonte: Scalabilità, disponibilità, stabilità, pattern

##### Svantaggio/i: replicazione master-master

##### Svantaggio(i): replica

##### Fonte(i) e ulteriori letture: replica

#### Federazione


Fonte: Scaling up to your first 10 million users

La federazione (o partizionamento funzionale) suddivide i database in base alla funzione. Ad esempio, invece di un singolo database monolitico, si potrebbero avere tre database: forum, utenti e prodotti, con conseguente minore traffico di lettura e scrittura per ogni database e quindi minore ritardo di replica. Database più piccoli permettono di memorizzare più dati in memoria, il che si traduce in più hit della cache grazie a una migliore località della cache. Non avendo un unico master centrale che serializza le scritture, è possibile scrivere in parallelo, aumentando il throughput.

##### Svantaggio(i): federazione

##### Fonte(i) e ulteriori letture: federazione

#### Sharding


Fonte: Scalability, availability, stability, patterns

Lo sharding distribuisce i dati tra diversi database in modo che ciascun database possa gestire solo un sottoinsieme dei dati. Prendendo come esempio un database utenti, man mano che il numero di utenti aumenta, si aggiungono altri shard al cluster.

Simile ai vantaggi della federazione, lo sharding comporta meno traffico di lettura e scrittura, meno replicazione e più cache hit. Anche la dimensione dell'indice si riduce, migliorando generalmente le prestazioni con query più veloci. Se uno shard si guasta, gli altri shard continuano a funzionare, anche se è consigliabile aggiungere una forma di replica per evitare la perdita di dati. Come la federazione, non esiste un unico master centrale che serializza le scritture, permettendo di scrivere in parallelo con maggiore throughput.

I modi comuni per shardare una tabella di utenti sono tramite l'iniziale del cognome dell'utente o la posizione geografica dell'utente.

##### Svantaggi: sharding

##### Fonte(e) e ulteriori letture: sharding

#### Denormalizzazione

La denormalizzazione cerca di migliorare le prestazioni di lettura a scapito di quelle di scrittura. Copie ridondanti dei dati vengono scritte in più tabelle per evitare join costosi. Alcuni RDBMS come PostgreSQL e Oracle supportano le materialized views che gestiscono il lavoro di memorizzazione delle informazioni ridondanti e mantengono le copie ridondanti coerenti.

Quando i dati vengono distribuiti con tecniche come federazione e sharding, la gestione dei join tra data center aumenta ulteriormente la complessità. La denormalizzazione può evitare la necessità di join così complessi.

Nella maggior parte dei sistemi, le letture possono superare di gran lunga le scritture, anche 100:1 o 1000:1. Una lettura che comporta un join complesso nel database può essere molto costosa, spendendo una notevole quantità di tempo in operazioni su disco.

##### Svantaggi: denormalizzazione

###### Fonte(e) e ulteriori letture: denormalizzazione

#### Ottimizzazione SQL

L'ottimizzazione SQL è un argomento ampio e molti libri sono stati scritti come riferimento.

È importante misurare e profilare per simulare e individuare i colli di bottiglia.

Le misurazioni e la profilazione potrebbero indirizzarti verso le seguenti ottimizzazioni.

##### Ottimizza lo schema

##### Usa buoni indici

##### Evita join costosi

##### Partiziona le tabelle

##### Ottimizza la cache delle query

##### Fonte(i) e ulteriori letture: ottimizzazione SQL

NoSQL

NoSQL è una collezione di elementi dati rappresentati in un key-value store, document store, wide column store o un graph database. I dati sono denormalizzati, e le join generalmente vengono effettuate nel codice dell'applicazione. La maggior parte degli archivi NoSQL non offre vere transazioni ACID e privilegia la consistenza eventuale.

BASE viene spesso utilizzato per descrivere le proprietà dei database NoSQL. In confronto al Teorema CAP, BASE sceglie la disponibilità rispetto alla consistenza.

Oltre a scegliere tra SQL o NoSQL, è utile capire quale tipo di database NoSQL si adatta meglio ai tuoi casi d'uso. Esamineremo key-value store, document store, wide column store e graph database nella prossima sezione.

#### Key-value store

Astrazione: tabella hash

Un key-value store generalmente consente letture e scritture O(1) ed è spesso supportato da memoria o SSD. Gli archivi dati possono mantenere le chiavi in ordine lessicografico, permettendo il recupero efficiente di intervalli di chiavi. I key-value store possono consentire la memorizzazione di metadati insieme a un valore.

I key-value store offrono alte prestazioni e sono spesso utilizzati per modelli dati semplici o per dati che cambiano rapidamente, come uno strato di cache in memoria. Poiché offrono solo un set limitato di operazioni, la complessità viene spostata al livello applicativo se sono necessarie operazioni aggiuntive.

Un key-value store è la base per sistemi più complessi come un document store, e in alcuni casi, un graph database.

##### Fonte(i) e ulteriori letture: key-value store

#### Document store

Astrazione: archivio chiave-valore con documenti memorizzati come valori

Un document store è incentrato sui documenti (XML, JSON, binari, ecc.), dove un documento memorizza tutte le informazioni relative a un determinato oggetto. I document store forniscono API o un linguaggio di query per interrogare sulla base della struttura interna del documento stesso. Nota, molti archivi chiave-valore includono funzionalità per lavorare con i metadati di un valore, sfumando la distinzione tra questi due tipi di archiviazione.

In base all'implementazione sottostante, i documenti sono organizzati in collezioni, tag, metadati o directory. Anche se i documenti possono essere organizzati o raggruppati insieme, i documenti possono avere campi completamente diversi tra loro.

Alcuni document store come MongoDB e CouchDB offrono anche un linguaggio simile a SQL per effettuare query complesse. DynamoDB supporta sia chiave-valore che documenti.

I document store offrono grande flessibilità e sono spesso utilizzati per lavorare con dati che cambiano occasionalmente.

##### Fonte(e) e ulteriori letture: document store

#### Wide column store


Fonte: SQL & NoSQL, una breve storia

Astrazione: mappa annidata ColumnFamily>

L'unità base di dati di un wide column store è una colonna (coppia nome/valore). Una colonna può essere raggruppata in famiglie di colonne (analogo a una tabella SQL). Le super column families raggruppano ulteriormente le famiglie di colonne. Puoi accedere a ciascuna colonna indipendentemente tramite una chiave di riga, e le colonne con la stessa chiave di riga formano una riga. Ogni valore contiene un timestamp per la versioning e la risoluzione dei conflitti.

Google ha introdotto Bigtable come primo wide column store, che ha influenzato l'open-source HBase spesso usato nell'ecosistema Hadoop, e Cassandra di Facebook. Archivi come BigTable, HBase e Cassandra mantengono le chiavi in ordine lessicografico, consentendo un recupero efficiente di intervalli selettivi di chiavi.

I wide column store offrono alta disponibilità e grande scalabilità. Sono spesso utilizzati per set di dati molto grandi.

##### Fonte(e) e ulteriori letture: wide column store

#### Database a grafo


Fonte: Database a grafo

Astrazione: grafo

In un database a grafo, ogni nodo è un record e ogni arco è una relazione tra due nodi. I database a grafo sono ottimizzati per rappresentare relazioni complesse con molte chiavi esterne o relazioni molti-a-molti.

I database a grafo offrono prestazioni elevate per modelli di dati con relazioni complesse, come una rete sociale. Sono relativamente nuovi e non sono ancora ampiamente utilizzati; potrebbe essere più difficile trovare strumenti di sviluppo e risorse. Molti grafi possono essere accessibili solo tramite REST API.

##### Fonte/i e ulteriori letture: grafo

#### Fonte/i e ulteriori letture: NoSQL

SQL o NoSQL


Fonte: Transizione da RDBMS a NoSQL

Motivi per SQL:

Motivi per NoSQL:

Esempi di dati adatti a NoSQL:

##### Fonte(e) e ulteriori letture: SQL o NoSQL

Cache


Fonte: Scalable system design patterns

La cache migliora i tempi di caricamento della pagina e può ridurre il carico sui server e sui database. In questo modello, il dispatcher controllerà prima se la richiesta è già stata effettuata e cercherà di trovare il risultato precedente da restituire, al fine di evitare l'esecuzione effettiva.

I database spesso beneficiano di una distribuzione uniforme di letture e scritture tra le sue partizioni. Gli elementi popolari possono alterare la distribuzione, causando colli di bottiglia. Mettere una cache davanti a un database può aiutare ad assorbire carichi irregolari e picchi di traffico.

Cache lato client

Le cache possono essere posizionate lato client (OS o browser), lato server, o in un livello di cache distinto.

Cache CDN

Le CDN sono considerate un tipo di cache.

Cache del web server

Reverse proxy e cache come Varnish possono servire direttamente contenuti statici e dinamici. I web server possono anche memorizzare le richieste in cache, restituendo risposte senza dover contattare i server applicativi.

Cache del database

Il tuo database di solito include un certo livello di cache nella configurazione predefinita, ottimizzata per un uso generico. Modificare queste impostazioni per specifici modelli di utilizzo può aumentare ulteriormente le prestazioni.

Cache applicativa

Le cache in memoria come Memcached e Redis sono archivi chiave-valore tra la tua applicazione e il tuo storage dati. Poiché i dati sono tenuti in RAM, sono molto più veloci rispetto ai database tipici dove i dati sono su disco. La RAM è più limitata del disco, quindi algoritmi di invalidazione della cache come least recently used (LRU)) possono aiutare a invalidare le voci "fredde" e mantenere i dati "caldi" in RAM.

Redis offre le seguenti funzionalità aggiuntive:

Esistono diversi livelli che puoi cacheare, che rientrano in due categorie generali: query di database e oggetti:

Generalmente, è meglio evitare la cache basata su file, poiché rende più difficile la clonazione e l'auto-scalabilità.

Caching a livello di query del database

Ogni volta che interroghi il database, usa l'hash della query come chiave e memorizza il risultato nella cache. Questo approccio presenta problemi di scadenza:

Caching a livello di oggetto

Vedi i tuoi dati come oggetti, simile a come fai con il codice della tua applicazione. Fai sì che la tua applicazione assembli il set di dati dal database in un'istanza di classe o in una/e struttura/e dati:

Suggerimenti su cosa memorizzare in cache:

Quando aggiornare la cache

Poiché puoi memorizzare solo una quantità limitata di dati in cache, dovrai determinare quale strategia di aggiornamento della cache funziona meglio per il tuo caso d'uso.

#### Cache-aside


Fonte: From cache to in-memory data grid

L'applicazione è responsabile della lettura e scrittura dallo storage. La cache non interagisce direttamente con lo storage. L'applicazione esegue le seguenti operazioni:

def get_user(self, user_id):
    user = cache.get("user.{0}", user_id)
    if user is None:
        user = db.query("SELECT * FROM users WHERE user_id = {0}", user_id)
        if user is not None:
            key = "user.{0}".format(user_id)
            cache.set(key, json.dumps(user))
    return user

Memcached viene generalmente utilizzato in questo modo.

Le letture successive dei dati aggiunti alla cache sono veloci. Il cache-aside è anche chiamato lazy loading. Solo i dati richiesti vengono memorizzati nella cache, evitando di riempire la cache con dati che non vengono richiesti.

##### Svantaggio/i: cache-aside

#### Write-through


Fonte: Scalability, availability, stability, patterns

L’applicazione utilizza la cache come principale archivio dati, leggendo e scrivendo dati su di essa, mentre la cache si occupa di leggere e scrivere sul database:

Codice dell’applicazione:

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

Codice cache:

def set_user(user_id, values):
    user = db.query("UPDATE Users WHERE id = {0}", user_id, values)
    cache.set(user_id, user)
La modalità write-through è generalmente un'operazione lenta a causa della scrittura, ma le letture successive dei dati appena scritti sono rapide. Gli utenti di solito sono più tolleranti alla latenza durante l'aggiornamento dei dati rispetto alla lettura dei dati. I dati nella cache non sono obsoleti.

##### Svantaggio/i: write-through

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


Fonte: Scalability, availability, stability, patterns

Nel write-behind, l'applicazione esegue le seguenti operazioni:

##### Svantaggio/i: write-behind

#### Refresh-ahead


Fonte: From cache to in-memory data grid

È possibile configurare la cache affinché aggiorni automaticamente qualsiasi voce della cache recentemente acceduta prima della sua scadenza.

Il refresh-ahead può comportare una latenza ridotta rispetto al read-through se la cache riesce a prevedere accuratamente quali elementi saranno necessari in futuro.

##### Svantaggio/i: refresh-ahead

Svantaggio(i): cache

Fonte(i) e letture aggiuntive

Asincronismo


Fonte: Introduzione all’architettura di sistemi scalabili

I flussi di lavoro asincroni aiutano a ridurre i tempi di richiesta per operazioni costose che altrimenti verrebbero eseguite in linea. Possono anche aiutare effettuando in anticipo lavori che richiedono tempo, come l'aggregazione periodica dei dati.

Code di messaggi

Le code di messaggi ricevono, trattengono e consegnano messaggi. Se un'operazione è troppo lenta per essere eseguita in linea, è possibile utilizzare una coda di messaggi con il seguente flusso:

L'utente non viene bloccato e il lavoro viene elaborato in background. Durante questo periodo, il client può opzionalmente eseguire una piccola quantità di elaborazione per far sembrare che il compito sia stato completato. Ad esempio, se si pubblica un tweet, il tweet potrebbe essere immediatamente pubblicato sulla propria timeline, ma potrebbe volerci del tempo prima che il tweet venga effettivamente consegnato a tutti i propri follower.

Redis è utile come semplice message broker, ma i messaggi possono andare persi.

RabbitMQ è popolare, ma richiede di adattarsi al protocollo 'AMQP' e di gestire i propri nodi.

Amazon SQS è ospitato ma può avere alta latenza e la possibilità che i messaggi vengano consegnati due volte.

Code di attività

Le code di attività ricevono le attività e i relativi dati, le eseguono e poi ne consegnano i risultati. Possono supportare la pianificazione e vengono utilizzate per eseguire lavori computazionalmente intensivi in background.

Celery supporta la pianificazione ed è principalmente compatibile con python.

Pressione inversa (Back pressure)

Se le code iniziano a crescere significativamente, la dimensione della coda può superare la memoria, causando cache miss, letture da disco e prestazioni ancora più lente. La pressione inversa può aiutare limitando la dimensione della coda, mantenendo così un alto tasso di throughput e buoni tempi di risposta per i lavori già in coda. Una volta che la coda è piena, i client ricevono un messaggio di server occupato o lo status code HTTP 503 per riprovare più tardi. I client possono ripetere la richiesta successivamente, magari con exponential backoff.

Svantaggio(i): asincronismo

Fonte(e) e ulteriori letture

Comunicazione


Fonte: modello OSI a 7 livelli

Hypertext transfer protocol (HTTP)

HTTP è un metodo per codificare e trasportare dati tra un client e un server. È un protocollo request/response: i client inviano richieste e i server rispondono con contenuti rilevanti e informazioni sullo stato di completamento della richiesta. HTTP è autonomo, consentendo che richieste e risposte fluiscano attraverso router e server intermedi che eseguono bilanciamento del carico, caching, crittografia e compressione.

Una richiesta HTTP di base consiste in un verbo (metodo) e una risorsa (endpoint). Di seguito sono riportati i verbi HTTP più comuni:

| Verbo | Descrizione | Idempotente* | Sicuro | Caching | |---|---|---|---|---| | GET | Legge una risorsa | Sì | Sì | Sì | | POST | Crea una risorsa o avvia un processo che gestisce dati | No | No | Sì se la risposta contiene info sulla freschezza | | PUT | Crea o sostituisce una risorsa | Sì | No | No | | PATCH | Aggiorna parzialmente una risorsa | No | No | Sì se la risposta contiene info sulla freschezza | | DELETE | Elimina una risorsa | Sì | No | No |

*Può essere chiamato molte volte senza risultati diversi.

HTTP è un protocollo di livello applicazione che si basa su protocolli di livello inferiore come TCP e UDP.

#### Fonte(e) e ulteriori letture: HTTP

Transmission control protocol (TCP)


Fonte: Come realizzare un gioco multiplayer

TCP è un protocollo orientato alla connessione su una rete IP. La connessione viene stabilita e terminata tramite una stretta di mano. Tutti i pacchetti inviati sono garantiti di raggiungere la destinazione nell'ordine originale e senza corruzione tramite:

Se il mittente non riceve una risposta corretta, ritrasmette i pacchetti. Se ci sono più timeout, la connessione viene chiusa. TCP implementa anche il controllo di flusso) e il controllo della congestione. Queste garanzie causano ritardi e generalmente portano a una trasmissione meno efficiente rispetto a UDP.

Per garantire un'elevata velocità di trasmissione, i server web possono mantenere aperte molte connessioni TCP, con conseguente elevato utilizzo di memoria. Può essere costoso avere molte connessioni aperte tra i thread del server web e, ad esempio, un server memcached. Il connection pooling può aiutare oltre alla commutazione su UDP dove applicabile.

TCP è utile per applicazioni che richiedono alta affidabilità ma sono meno critiche in termini di tempo. Alcuni esempi includono server web, info di database, SMTP, FTP e SSH.

Usa TCP invece di UDP quando:

Protocollo User Datagram (UDP)


Fonte: How to make a multiplayer game

UDP è senza connessione. I datagrammi (analoghi ai pacchetti) sono garantiti solo a livello di datagramma. I datagrammi possono arrivare a destinazione fuori ordine o non arrivare affatto. UDP non supporta il controllo della congestione. Senza le garanzie offerte da TCP, UDP è generalmente più efficiente.

UDP può trasmettere in broadcast, inviando datagrammi a tutti i dispositivi sulla sottorete. Questo è utile con DHCP perché il client non ha ancora ricevuto un indirizzo IP, impedendo così a TCP di trasmettere senza l’indirizzo IP.

UDP è meno affidabile, ma funziona bene in casi d’uso in tempo reale come VoIP, videochat, streaming e giochi multiplayer in tempo reale.

Usa UDP invece di TCP quando:

#### Fonte(i) e letture aggiuntive: TCP e UDP

Remote procedure call (RPC)


Fonte: Crack the system design interview

In una RPC, un client fa eseguire una procedura su uno spazio di indirizzi diverso, di solito un server remoto. La procedura è scritta come se fosse una chiamata locale, astrarre i dettagli di come comunicare con il server dal programma client. Le chiamate remote sono solitamente più lente e meno affidabili delle chiamate locali, quindi è utile distinguere tra chiamate RPC e chiamate locali. Framework RPC popolari includono Protobuf, Thrift, e Avro.

RPC è un protocollo richiesta-risposta:

Esempi di chiamate RPC:

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

RPC si concentra sull'esposizione dei comportamenti. Gli RPC vengono spesso utilizzati per motivi di prestazioni nelle comunicazioni interne, poiché è possibile creare chiamate native su misura per adattarsi meglio ai propri casi d'uso.

Scegli una libreria nativa (nota anche come SDK) quando:

Le API HTTP che seguono REST tendono ad essere utilizzate più frequentemente per le API pubbliche.

#### Svantaggio/i: RPC

Trasferimento di stato rappresentazionale (REST)

REST è uno stile architetturale che applica un modello client/server in cui il client agisce su un insieme di risorse gestite dal server. Il server fornisce una rappresentazione delle risorse e azioni che possono manipolare o ottenere una nuova rappresentazione delle risorse. Tutta la comunicazione deve essere senza stato e cacheabile.

Ci sono quattro qualità di un'interfaccia RESTful:

Esempi di chiamate REST:

GET /someresources/anId
PUT /someresources/anId
{"anotherdata": "another value"}

REST è focalizzato sull’esposizione dei dati. Minimizza il coupling tra client/server ed è spesso utilizzato per API HTTP pubbliche. REST utilizza un metodo più generico e uniforme per esporre le risorse tramite URI, rappresentazione tramite header e azioni tramite verbi come GET, POST, PUT, DELETE e PATCH. Essendo stateless, REST è ottimo per lo scaling orizzontale e il partizionamento.

#### Svantaggio(i): REST

Confronto tra chiamate RPC e REST

| Operazione | RPC | REST | |---|---|---| | Registrazione | POST /signup | POST /persons | | Dimissioni | POST /resign
{
"personid": "1234"
} | DELETE /persons/1234 | | Leggi una persona | GET /readPerson?personid=1234 | GET /persons/1234 | | Leggi la lista oggetti di una persona | GET /readUsersItemsList?personid=1234 | GET /persons/1234/items | | Aggiungi un oggetto alla lista di una persona | POST /addItemToUsersItemsList
{
"personid": "1234";
"itemid": "456"
} | POST /persons/1234/items
{
"itemid": "456"
} | | Aggiorna un oggetto | POST /modifyItem
{
"itemid": "456";
"key": "value"
} | PUT /items/456
{
"key": "value"
} | | Elimina un oggetto | POST /removeItem
{
"itemid": "456"
} | DELETE /items/456 |

Fonte: Do you really know why you prefer REST over RPC

#### Fonte/i e ulteriori letture: REST e RPC

Sicurezza

Questa sezione potrebbe necessitare di aggiornamenti. Prendi in considerazione di contribuire!

La sicurezza è un argomento ampio. A meno che tu non abbia una notevole esperienza, un background in sicurezza, o stia facendo domanda per una posizione che richiede conoscenze di sicurezza, probabilmente non avrai bisogno di sapere più delle basi:

Fonte(e) e ulteriori letture

Appendice

A volte ti verrà chiesto di fare stime "a spanne". Ad esempio, potresti dover determinare quanto tempo ci vorrà per generare 100 miniature di immagini da disco o quanta memoria occuperà una struttura dati. La tabella delle potenze di due e i numeri di latenza che ogni programmatore dovrebbe conoscere sono riferimenti utili.

Tabella delle potenze di due

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

#### Fonte(e) e ulteriori letture

Numeri di latenza che ogni programmatore dovrebbe conoscere

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD     30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms
Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns
Metriche utili basate sui numeri sopra:

#### Numeri di latenza visualizzati

#### Fonte/i e letture aggiuntive

Ulteriori domande per colloqui di progettazione di sistemi

Domande comuni dei colloqui di progettazione di sistemi, con link a risorse su come risolverle.

| Domanda | Riferimento/i | |---|---| | Progetta un servizio di sincronizzazione file come Dropbox | youtube.com | | Progetta un motore di ricerca come Google | queue.acm.org
stackexchange.com
ardendertat.com
stanford.edu | | Progetta un web crawler scalabile come Google | quora.com | | Progetta Google docs | code.google.com
neil.fraser.name | | Progetta un key-value store come Redis | slideshare.net | | Progetta un sistema di cache come Memcached | slideshare.net | | Progetta un sistema di raccomandazione come quello di Amazon | hulu.com
ijcai13.org | | Progetta un sistema tinyurl come Bitly | n00tc0d3r.blogspot.com | | Progetta un'app di chat come WhatsApp | highscalability.com | Progetta un sistema di condivisione immagini come Instagram | highscalability.com
highscalability.com | | Progetta la funzione news feed di Facebook | quora.com
quora.com
slideshare.net | | Progetta la funzione timeline di Facebook | facebook.com
highscalability.com | | Progetta la funzione chat di Facebook | erlang-factory.com
facebook.com |

| Progetta una funzione di ricerca su grafi come quella di Facebook | facebook.com
facebook.com
facebook.com | | Progetta una content delivery network come CloudFlare | figshare.com | | Progetta un sistema di argomenti di tendenza come quello di Twitter | michael-noll.com
snikolov .wordpress.com | | Progetta un sistema di generazione di ID casuali | blog.twitter.com
github.com | | Restituisci le top k richieste durante un intervallo di tempo | cs.ucsb.edu
wpi.edu | | Progetta un sistema che serve dati da più data center | highscalability.com | | Progetta un gioco di carte multiplayer online | indieflashblog.com
buildnewgames.com | | Progetta un sistema di garbage collection | stuffwithstuff.com
washington.edu | | Progetta un sistema di limitazione delle API | https://stripe.com/blog/ | | Progetta una Borsa Valori (come NASDAQ o Binance) | Jane Street
Golang Implementation
Go Implementation | | Aggiungi una domanda di system design | Contribuisci |

Architetture del mondo reale

Articoli su come sono progettati i sistemi nel mondo reale.


Fonte: Twitter timelines at scale

Non concentrarti sui dettagli minuziosi per i seguenti articoli, invece:

|Tipo | Sistema | Riferimento/i | |---|---|---| | Data processing | MapReduce - Elaborazione dati distribuita di Google | research.google.com | | Data processing | Spark - Elaborazione dati distribuita di Databricks | slideshare.net | | Data processing | Storm - Elaborazione dati distribuita di Twitter | slideshare.net | | | | | | Data store | Bigtable - Database distribuito orientato alle colonne di Google | harvard.edu | | Data store | HBase - Implementazione open source di Bigtable | slideshare.net | | Data store | Cassandra - Database distribuito orientato alle colonne di Facebook | slideshare.net | Data store | DynamoDB - Database orientato ai documenti di Amazon | harvard.edu | | Data store | MongoDB - Database orientato ai documenti | slideshare.net | | Data store | Spanner - Database distribuito globalmente di Google | research.google.com | | Data store | Memcached - Sistema di caching della memoria distribuito | slideshare.net | | Data store | Redis - Sistema di caching della memoria distribuito con persistenza e tipi di valore | slideshare.net | | | | | | File system | Google File System (GFS) - File system distribuito | research.google.com | | File system | Hadoop File System (HDFS) - Implementazione open source di GFS | apache.org | | | | | | Misc | Chubby - Servizio di lock per sistemi distribuiti loosely-coupled di Google | research.google.com | | Misc | Dapper - Infrastruttura di tracciamento per sistemi distribuiti | research.google.com | Misc | Kafka - Coda di messaggi pub/sub di LinkedIn | slideshare.net | | Misc | Zookeeper - Infrastruttura centralizzata e servizi per l'abilitazione della sincronizzazione | slideshare.net | | | Aggiungi un'architettura | Contribuisci |

Architetture aziendali

| Azienda | Riferimento/i | |---|---| | Amazon | Architettura Amazon | | Cinchcast | Produzione di 1.500 ore di audio ogni giorno | | DataSift | Datamining in tempo reale a 120.000 tweet al secondo | | Dropbox | Come abbiamo scalato Dropbox | | ESPN | Operatività a 100.000 duh nuh nuhs al secondo | | Google | Architettura Google | | Instagram | 14 milioni di utenti, terabyte di foto
Cosa alimenta Instagram | | Justin.tv | Architettura di trasmissione video live di Justin.Tv | | Facebook | Scalare memcached su Facebook
TAO: Data store distribuito di Facebook per il social graph
Lo storage delle foto su Facebook
Come Facebook Live trasmette a 800.000 spettatori simultanei | | Flickr | Architettura Flickr | | Mailbox | Da 0 a un milione di utenti in 6 settimane | | Netflix | Vista a 360 gradi dell'intero stack Netflix
Netflix: cosa succede quando premi Play? | | Pinterest | Da 0 a decine di miliardi di pageview al mese
18 milioni di visitatori, crescita 10x, 12 dipendenti | | Playfish | 50 milioni di utenti mensili e in crescita | | PlentyOfFish | Architettura PlentyOfFish | | Salesforce | Come gestiscono 1,3 miliardi di transazioni al giorno | | Stack Overflow | Architettura Stack Overflow | | TripAdvisor | 40M visitatori, 200M pageview dinamiche, 30TB dati | | Tumblr | 15 miliardi di pageview al mese | | Twitter | Rendere Twitter il 10000 percento più veloce
Memorizzare 250 milioni di tweet al giorno usando MySQL
150M utenti attivi, 300K QPS, un firehose da 22 MB/S
Timeline su larga scala
Big e small data su Twitter
Operazioni su Twitter: scaling oltre 100 milioni di utenti
Come Twitter gestisce 3.000 immagini al secondo | | Uber | Come Uber scala la propria piattaforma di mercato in tempo reale
Lezioni apprese scalando Uber a 2000 ingegneri, 1000 servizi e 8000 repository Git | | WhatsApp | L'architettura di WhatsApp che Facebook ha acquistato per 19 miliardi di dollari | | YouTube | Scalabilità di YouTube
Architettura YouTube |

Blog di ingegneria aziendale

Architetture delle aziende con cui stai facendo colloqui.
>
Le domande che incontri potrebbero provenire dallo stesso dominio.

#### Fonte(i) e ulteriori letture

Vuoi aggiungere un blog? Per evitare di duplicare il lavoro, considera di aggiungere il blog della tua azienda al seguente repository:

In fase di sviluppo

Sei interessato ad aggiungere una sezione o aiutare a completarne una in corso? Contribuisci!

Crediti

I crediti e le fonti sono forniti in tutto questo repository.

Un ringraziamento speciale a:

Info di contatto

Sentiti libero di contattarmi per discutere qualsiasi problema, domanda o commento.

Le mie informazioni di contatto sono disponibili sulla mia pagina GitHub.

Licenza

Sto fornendo codice e risorse in questo repository sotto una licenza open source. Poiché questo è il mio repository personale, la licenza che ricevi per il mio codice e le risorse proviene da me e non dal mio datore di lavoro (Facebook).

Copyright 2017 Donne Martin

Creative Commons Attribution 4.0 International License (CC BY 4.0)

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

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

Original README: View on GitHub

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