b'\n_START_ARTICLE_\nTeorema CAP\n_START_SECTION_\nStoria\n_START_PARAGRAPH_\nL\'enunciato del teorema venne ideato dall\'informatico statunitense Eric Brewer all\'Universit\xc3\xa0 della California, Berkeley nell\'autunno del 1998. Venne pubblicato nel 1999 come "principio CAP" e successivamente presentato come congettura dallo stesso Brewer al simposio Principles of Distributed Computing (PODC) che ebbe luogo nel 2000. Nel 2002, Seth Gilbert e Nancy Lynch del MIT pubblicarono una dimostrazione formale della congettura di Brewer, facendola assurgere al rango di teorema._NEWLINE_Il teorema CAP, come dimostrato da Gilbert e Lynch, \xc3\xa8 un po\' pi\xc3\xb9 limitato di quello che Brewer aveva in mente. Il teorema stabilisce uno scenario in cui viene presentato un servizio replicato con due richieste in conflitto che arrivano in luoghi distinti nel momento in cui il collegamento tra di loro \xc3\xa8 fallito. L\'obbligo di fornire la disponibilit\xc3\xa0 nonostante gli errori di partizionamento porta i servizi a rispondere; almeno una di queste risposte sar\xc3\xa0 necessariamente in contrasto con ci\xc3\xb2 che un servizio che implementa una vera e propria replica semantica one-copy avrebbe fatto. I ricercatori vanno poi avanti per dimostrare che altre forme di consistenza sono realizzabili, tra cui una propriet\xc3\xa0 che chiamano coerenza t-eventuale. Cos\xc3\xac il teorema non esclude la fattibilit\xc3\xa0 della coerenza di un sistema distribuito, e non dice nulla circa il cloud in s\xc3\xa9 o sulla scalabilit\xc3\xa0._NEWLINE_Al contrario, come Eric Brewer ha posto la domanda, CAP \xc3\xa8 spesso volto ad escludere la consistenza per i servizi in esecuzione in alta elasticit\xc3\xa0 di primo livello di un moderno sistema di cloud computing. A questi servizi \xc3\xa8 richiesto generalmente di essere stateless o di mantenere solo un soft-state (dati memorizzati nella cache), e di essere reattivi anche se servizi ad un livello pi\xc3\xb9 interno sono temporaneamente inaccessibili. CAP, in questo senso, usa "A" per indicare immediatamente reattivo, e "P" per dire "anche se un guasto impedisce al primo livello di servizio di connettersi ad una risorsa necessaria". In effetti, sacrifichiamo la coerenza per ottenere risposte pi\xc3\xb9 veloci in modo pi\xc3\xb9 scalabile._NEWLINE_Si noti che il partizionamento in s\xc3\xa9 in realt\xc3\xa0 non entra in questa interpretazione estensiva del teorema CAP. Infatti, non c\'\xc3\xa8 un teorema CAP per lo scenario effettivamente visto in cui la disponibilit\xc3\xa0 simmetrica in caso di guasto del partizionamento non sia normalmente richiesta. Ci sono due ragioni per questo: la prima, le piattaforme cloud dispongono di reti ridondanti ad alta disponibilit\xc3\xa0 e normalmente non sono affette da questi guasti. In secondo luogo, se uno di questi eventi molto rari di partizionamento si verificasse, _NEWLINE_sarebbe molto probabile tagliare fuori alcune piccole porzioni della replica, non solo dalle altre componenti del cloud ma anche dai loro client esterni, ovviando alla necessit\xc3\xa0 di disponibilit\xc3\xa0._NEWLINE_Il teorema CAP \xc3\xa8 spesso citato come una giustificazione per l\'utilizzo di modelli di consistenza pi\xc3\xb9 deboli. Popolare tra questi \xc3\xa8 BASE, acronimo di Basically Available Soft-state (services with) Eventual consistency ("(servizi con) consistenza effettiva, soft-state, fondamentalmente disponibile"). In sintesi, la metodologia BASE \xc3\xa8 caratterizzata da una elevata disponibilit\xc3\xa0 per i servizi di primo livello, lasciando un qualche tipo di meccanismo di pulizia di fondo per risolvere i problemi creati da azioni ottimistiche che poi risultano avere violato la consistenza.'