From 474bc7a921cae9edc6d13c20832684a56b8f01ef Mon Sep 17 00:00:00 2001
From: Fernando Machado <fmachadopiriz@outlook.com>
Date: Sun, 3 Nov 2024 09:26:04 -0300
Subject: [PATCH 1/3] Work in progress

---
 4_Conceptos/4_ACID.md |  75 ++++++++++++++++++
 4_Conceptos/4_BASE.md | 174 ++++++++++++++++++++++++++++++++++++++++++
 4_Conceptos/4_CAP.md  |  90 ++++++++++++++++++++++
 3 files changed, 339 insertions(+)
 create mode 100644 4_Conceptos/4_ACID.md
 create mode 100644 4_Conceptos/4_BASE.md
 create mode 100644 4_Conceptos/4_CAP.md

diff --git a/4_Conceptos/4_ACID.md b/4_Conceptos/4_ACID.md
new file mode 100644
index 0000000..4f5da40
--- /dev/null
+++ b/4_Conceptos/4_ACID.md
@@ -0,0 +1,75 @@
+# 4 Conceptos
+
+## ACID
+
+ACID es un [acrónimo](https://dle.rae.es/acrónimo) que referencia las cuatro
+propiedades de una transacción: atomicidad, consistencia, aislamiento
+—*isolation* en inglés— y durabilidad[^1].
+
+[^1]: Haerder, T.; Reuter, A. (1983). Principles of Transaction-Oriented
+    Database Recovery. ACM Computing Surveys (CSUR), 15(4). Disponible
+    [aquí](https://dl.acm.org/doi/10.1145/289.291).
+
+Compáralo con [BASE](./4_BASE.md).
+
+La transacción básicamente refleja la idea de que las actividades de un usuario
+en particular estén aisladas de todas las demás actividades concurrentes —de
+otros usuarios u otros procesos—, pero restringe el grado de aislamiento y la
+duración de la transacción. Típicamente una transacción es una secuencia corta
+de interacciones con la base de datos, tales como encontrar o modificar un
+elemento, que representa una actividad significativa en el contexto del
+usuario[^1].
+
+### Atomicidad
+
+Las interacciones en una transacción deben ser indivisibles: o bien todas
+se reflejan de forma apropiada en los datos, o bien no ocurre ningún cambio.
+Además, el usuario debe saber qué ha ocurrido, en qué estado ha quedado.
+
+La atomicidad garantiza que una transacción se trate como una sola unidad de
+trabajo. Puede completarse completamente o no completarse en absoluto como si
+nada hubiera ocurrido. En caso de que ocurra una falla durante una transacción,
+se revierte —*rollback*— toda la transacción.
+
+### Consistencia
+
+Cada transacción que se completa de forma exitosa produce solamente resultados
+correctos, es decir, se cumplen todas las reglas que se hayan definido.
+
+La consistencia garantiza que una transacción mueve el conjunto de datos de un
+estado válido a otro estado también válido, lo que garantiza que se cumplan
+todas las reglas establecidas sobre los datos —por ejemplo la integridad
+referencial—.
+
+### Aislamiento
+
+Los eventos en una transacción deben quedar ocultos a otras transacciones que
+estén ejecutándose de forma concurrente.
+
+El aislamiento garantiza que las transacciones se ejecuten de forma
+independiente unas de otras. Los distintos motores gestionan el aislamiento a
+través de niveles de aislamiento —por ejemplo, [read
+committed](https://www.postgresql.org/docs/current/transaction-iso.html#XACT-READ-COMMITTED),
+[repeatable
+read](https://www.postgresql.org/docs/current/transaction-iso.html#XACT-REPEATABLE-READ),o
+[serializable](https://www.postgresql.org/docs/current/transaction-iso.html#XACT-SERIALIZABLE))
+para evitar problemas de concurrencia, como lecturas sucias o lecturas fantasma.
+
+### Durabilidad
+
+Una vez que una transacción se ha completado de forma exitosa, sus cambios son
+permanentes, aún en el caso de un fallo del sistema.
+
+### ACID más allá de bases de datos
+
+Aunque el concepto surgió inicialmente en el contexto de bases de datos, hoy se
+utiliza en otros contextos en los que haya manipulación y acceso a datos o
+eventos.
+
+Las plataformas de colas de mensajes garantizan la durabilidad persistiendo los mensajes
+recibidos hasta que sean procesados y removidos de la cola. La atomicidad se
+logra asegurando que los mensajes se entregan por completo o no se entregan; si
+ocurre un error durante la transmisión de un mensaje, no se procesan mensajes
+parcialmente recibidos. En algunos casos el aislamiento se logra utilizando
+tópicos o múltiples colas, para asegurar que consumidores concurrentes no
+interfieren entre ellos.
diff --git a/4_Conceptos/4_BASE.md b/4_Conceptos/4_BASE.md
new file mode 100644
index 0000000..87eef2f
--- /dev/null
+++ b/4_Conceptos/4_BASE.md
@@ -0,0 +1,174 @@
+# 4 Conceptos
+
+## BASE y consistencia eventual
+
+Gracias al [teorema CAP](./4_CAP.md) sabemos que en los sistemas que
+proporcionan alta disponibilidad a través de redundancia mediante réplicas,
+dadas las propiedades de consistencia, alta disponibilidad y resiliencia a la
+partición, sólo es posible cumplir a la vez dos como máximo, nunca las tres al
+mismo tiempo.
+
+Los sistemas de este tipo que priorizan la disponibilidad sobre la consistencia
+suelen permitir inconsistencias por cierto tiempo, con la expectativa de que se
+alcanzará un estado consistente después. Esto da lugar al llamado paradigma
+BASE[^1].
+
+[^1]: Vogels, W. (2009). Eventually Consistent. Communications of the ACM,
+    January 2009, 52(1). Disponible
+    [aquí](https://dl.acm.org/doi/pdf/10.1145/1435417.1435432).
+
+BASE en un acrónimo [acrónimo](https://dle.rae.es/acrónimo) que referencia las
+características de este tipo de sistemas: disponibilidad básica —***b**asic
+**a**vailability* en inglés—, estado blando —***s**oft state* en inglés— y
+consistencia eventual —***e**ventual consistency* en inglés—. *base* se traduce
+como base, lo contrario a ácido en química, por lo que BASE sería lo contrario a
+[ACID](./4_ACID.md)—
+
+Hay dos formas de ver la consistencia:
+
+* Una es desde el punto de vista del desarrollador o del cliente del sistema:
+  cómo observan las actualizaciones de datos.
+
+* La otra es desde el lado del servidor: cómo fluyen las actualizaciones a
+  través del sistema y qué garantías puede dar con respecto a las
+  actualizaciones.
+
+Los componentes del lado del cliente incluyen:
+
+* Un sistema de almacenamiento. Lo trataremos como una caja
+  negra, pero asumiendo que en el fondo es algo de gran escala y altamente
+  distribuido, y que está construido para garantizar la durabilidad y la
+  disponibilidad.
+
+* Un proceso A. Este es un proceso que escribe y que lee desde el sistema de
+  almacenamiento.
+
+* Procesos B y C. Estos procesos son independientes del proceso A y escriben y
+  leen desde el sistema de almacenamiento.Es irrelevante si estos son realmente
+  procesos o sub-procesos dentro del mismo proceso; lo que es importante es que
+  son independientes y que necesitan comunicarse para compartir información.
+
+### Consistencia eventual del lado del cliente
+
+La consistencia del lado del cliente tiene que ver con cómo y cuándo los
+observadores —en este caso los procesos A, B o C— ven las actualizaciones
+realizadas a los objetos de datos en el sistemas de almacenamiento.
+
+En los siguientes ejemplos que ilustran los diferentes tipos de consistencia, el
+proceso A ha realizado una actualización a un elemento de datos:
+
+* **Consistencia fuerte**. Una vez que se completa la actualización, cualquier
+  acceso posterior —por parte de A, B o C— devolverá el valor actualizado.
+
+* **Consistencia débil**. El sistema no garantiza que los accesos posteriores
+  devolverán el valor actualizado. Se deben cumplir varias condiciones antes de
+  que se devuelva el valor. El período entre la actualización y el momento en el
+  que se garantiza que cualquier observador siempre verá el valor actualizado se
+  denomina **ventana de inconsistencia**.
+
+* **Consistencia eventual**. Esta es una forma específica de consistencia débil:
+  el sistema de almacenamiento garantiza que si no se realizan nuevas
+  actualizaciones al elemento de datos, eventualmente todos los accesos devolverán
+  el último valor actualizado. Si no se producen fallos, el tamaño máximo de la
+  ventana de inconsistencia se puede determinar en función de factores como los
+  retrasos en la comunicación, la carga del sistema y la cantidad de réplicas
+  involucradas en el esquema de replicación[^2].
+
+[^2]: El sistema más popular que implementa la consistencia eventual es el
+    [sistema de nombres de
+    dominio](https://datatracker.ietf.org/doc/html/rfc1034) —DNS por sus siglas
+        en inglés *domain name system*—. Las actualizaciones de un nombre se
+    distribuyen de acuerdo con un patrón configurado y en combinación con cachés
+    controlados por tiempo; finalmente, todos los clientes verán la
+    actualización.
+
+El modelo de consistencia eventual tiene varias variaciones que es importante
+tener en cuenta:
+
+* **Consistencia causal**. Si el proceso A ha comunicado al proceso B que ha
+  actualizado un elemento de datos, un acceso posterior por parte del proceso B
+  devolverá el valor actualizado y se garantiza que una escritura reemplazará a
+  la escritura anterior. El acceso por parte del proceso C que no tiene una
+  relación causal con el proceso A está sujeto a las reglas normales de
+  consistencia eventual.
+
+* **Consistencia de lectura de escrituras**. Este es un modelo importante en el
+  que el proceso A, después de haber actualizado un elemento de datos, siempre
+  accede al valor actualizado y nunca ve un valor anterior. Este es un caso
+  especial del modelo de consistencia causal.
+
+* **Consistencia de sesión**. Esta es una versión práctica del modelo anterior,
+  en el que un proceso accede al sistema de almacenamiento en el contexto de una
+  sesión. Mientras exista la sesión, el sistema garantiza la consistencia de
+  lectura y escritura. Si la sesión finaliza debido a una falla, se debe crear
+  una nueva sesión y las garantías no pasan de una sesión a otra.
+
+* **Consistencia de lectura monótona**. Si un proceso ha visto un valor
+  particular para el elemento de datos, cualquier acceso posterior nunca
+  devolverá ningún valor anterior.
+
+* **Consistencia de escritura monótona**. En este caso, el sistema garantiza
+  serializar las escrituras por el mismo proceso. Los sistemas que no garantizan
+  este nivel de consistencia son notoriamente difíciles de programar.
+
+Se pueden combinar varias de estas propiedades. Por ejemplo, se pueden obtener
+lecturas monótonas combinadas con consistencia a nivel de sesión. Desde un punto
+de vista práctico, estas dos propiedades —lecturas monótonas y lecturas de
+escrituras— son las más deseables en un sistema de consistencia eventual, pero
+no siempre son necesarias. Estas dos propiedades hacen que sea más sencillo para
+los desarrolladores crear aplicaciones, al tiempo que permiten que el sistema de
+almacenamiento relaje la consistencia y proporcione alta disponibilidad.
+
+### Consistencia eventual del lado del servidor
+
+En el lado del servidor, debemos analizar en profundidad cómo fluyen las
+actualizaciones a través del sistema para comprender qué impulsa los diferentes
+modos que puede experimentar el desarrollador que utiliza el sistema.
+
+Algunas definiciones antes de comenzar:
+
+* $N$ es la cantidad de nodos que almacenan réplicas de los datos.
+
+* $W$ es la cantidad de réplicas que deben confirmar la recepción de la
+  actualización antes de que esta se complete.
+
+* $R$ es la cantidad de réplicas que se contactan cuando se accede a un objeto de
+  datos a través de una operación de lectura.
+
+Si $W+R>N$, entonces el conjunto de escritura y el conjunto de lectura siempre
+se superponen y se puede garantizar la consistencia fuerte.
+
+Por ejemplo, en el escenario de un motor de bases de datos de copia de seguridad
+primaria, que implementa la replicación sincrónica —[*availability
+group*](https://learn.microsoft.com/en-us/sql/database-engine/sql-server-business-continuity-dr?view=sql-server-ver16#availability-groups)
+en SQL Server por ejemplo—, $N=2$, $W=2$ y $R=1$; sin importar desde qué réplica
+lea el cliente, siempre obtendrá una respuesta coherente. En el caso de
+replicación asíncrona con lectura desde la copia de seguridad habilitada —[*log
+shipping*](https://learn.microsoft.com/en-us/sql/database-engine/sql-server-business-continuity-dr?view=sql-server-ver16#log-shipping)
+en SQL Server por ejemplo—, $N=2$, $W=1$ y $R=1$; en este caso, $R+W=N$ y no se
+puede garantizar la coherencia.
+
+El problema con estas configuraciones es que cuando debido a fallas el sistema
+no puede escribir en $W$ nodos, la operación de escritura tiene que fallar, lo
+que implica que el sistema no está disponible. Con $N=3$ y $W=3$ y solo dos
+nodos disponibles, el sistema tendrá que fallar la escritura.
+
+En sistemas de almacenamiento distribuido que brindan alto rendimiento y alta
+disponibilidad, el número de réplicas es en general mayor que dos. Los sistemas
+que se enfocan únicamente en la tolerancia a fallas a menudo usan $N=3$ —con
+configuraciones $W=2$ y $R=2$—.
+
+Los sistemas que deben atender cargas de lectura muy altas a menudo replican sus
+datos más allá de lo que se requiere para la tolerancia a fallas; $N$ puede ser
+decenas o incluso cientos de nodos, con $R$ configurado en 1 de modo que una sola
+lectura devuelva un resultado. Los sistemas que se preocupan por la consistencia
+se configuran en $W=N$ para las actualizaciones, lo que puede reducir la
+probabilidad de que la escritura tenga éxito. Una configuración común para estos
+sistemas que se preocupan por la tolerancia a fallas pero no por la consistencia
+es ejecutar con W=1 para obtener una durabilidad mínima de la actualización y
+luego confiar en una técnica perezosa (epidémica) para actualizar las otras
+réplicas.
+
+La forma de configurar N, W y R depende de cuál sea el caso común y qué ruta de rendimiento se necesita optimizar. En R=1 y N=W optimizamos para el caso de lectura, y en W=1 y R=N optimizamos para una escritura muy rápida.
+Por supuesto, en el último caso, la durabilidad no está garantizada en presencia de fallas, y si W < (N+1)/2, existe la posibilidad de escrituras conflictivas cuando los conjuntos de escritura no se superponen.
+La consistencia débil/eventual surge cuando W+R <= N, lo que significa que existe la posibilidad de que el conjunto de lectura y escritura no se superpongan. Si esta es una configuración deliberada y no se basa en un caso de falla, entonces casi no tiene sentido establecer R en algo que no sea 1. Esto sucede en dos casos muy comunes: el primero es la replicación masiva para el escalamiento de lectura mencionado anteriormente; El segundo es donde el acceso a los datos es más complicado. En un modelo clave-valor simple es fácil comparar versiones para determinar el último valor escrito en el sistema, pero en sistemas que devuelven conjuntos de objetos es más difícil determinar cuál debería ser el último conjunto correcto. En la mayoría de estos sistemas donde el conjunto de escritura es más pequeño que el conjunto de réplicas, existe un mecanismo que aplica las actualizaciones de manera diferida a los nodos restantes en el conjunto de la réplica. El período hasta que se hayan actualizado todas las réplicas es la ventana de inconsistencia discutida anteriormente. Si W+R <= N, entonces el sistema es vulnerable a la lectura de nodos que aún no han recibido las actualizaciones.
\ No newline at end of file
diff --git a/4_Conceptos/4_CAP.md b/4_Conceptos/4_CAP.md
new file mode 100644
index 0000000..9a7c73d
--- /dev/null
+++ b/4_Conceptos/4_CAP.md
@@ -0,0 +1,90 @@
+# Conceptos
+
+## Teorema CAP
+
+Las aplicaciones modernas a escala de Internet deben afrontar altas expectativas
+de [disponibilidad](./4_Disponibilidad.md) y [rendimiento](./4_Rendimiento.md)
+antes cargas de usuarios en crecimiento exponencial. Estas aplicaciones se
+supone que se proporcionan alta disponibilidad a través de redundancia —por
+ejemplo, replicación de datos—; los datos se consideran altamente disponibles si
+un consumidor determinado de los datos siempre puede acceder a alguna réplica.
+La escala de estas aplicaciones está poniendo de manifiesto claramente el
+equilibrio entre consistencia y disponibilidad[^1].
+
+[^1]: Fox, A; Brewer, E. (1999). Harvest, Yield and Scalable Tolerant Systems.
+    Proc. 7th Workshop Hot Topics in Operating Systems, IEEE CS. Disponible
+    [aquí](https://s3.amazonaws.com/systemsandpapers/papers/FOX_Brewer_99-Harvest_Yield_and_Scalable_Tolerant_Systems.pdf).
+
+En este contexto, la consistencia fuerte significa consistencia
+[ACID](./4_Acoplamiento.md) de copia única; la alta disponibilidad se
+proporciona a través de la redundancia; la resiliencia a la partición significa
+que el sistema en su totalidad puede sobrevivir a una partición entre réplicas
+de datos[^1][^3].
+
+[^3]: Vogels, W. (2009). Eventually Consistent. Communications of the ACM,
+    January 2009, 52(1). Disponible
+    [aquí](https://dl.acm.org/doi/pdf/10.1145/1435417.1435432).
+
+Una partición ocurre cuando un conjunto de réplicas no puede acceder a otro
+conjunto de réplicas —lo que implica que los datos redundantes en las réplicas
+no pueden ser sincronizados—, pero ambos conjuntos son accesibles por un grupo
+de clientes.
+
+CAP es un [acrónimo](https://dle.rae.es/acrónimo) que establece compromisos
+entre estas tres propiedades: **c**onsistencia fuerte, alta disponibilidad
+—***a**vailability* en inglés—, y resistencia a la **p**artición de la red. El
+principio CAP fuerte establece que entre consistencia fuerte, alta
+disponibilidad y resiliencia a la partición sólo es posible cumplir a la vez dos
+como máximo, nunca los tres. Para demostrar el principio —de ahí que algunos lo
+llamen teorema CAP— es posible considerar todas las combinaciones posibles de
+forma exhaustiva[^1]:
+
+* CA sin P: Las bases de datos que proporcionan semántica transaccional
+  distribuida solo pueden hacerlo en ausencia de una partición de red que separe
+  la réplicas.
+
+* CP sin A: En caso de una partición, las transacciones posteriores a una base
+  de datos ACID pueden bloquearse hasta que la partición se recupere, para
+  evitar el riesgo de introducir conflictos de sincronización —y por lo tanto
+  inconsistencia—.
+
+* AP sin C: El almacenamiento en caché web HTTP proporciona resiliencia de
+  partición cliente-servidor al replicar documentos, pero una partición
+  cliente-servidor impide la verificación de la frescura de una réplica vencida.
+  En general, cualquier problema de base de datos distribuida puede resolverse
+  con un almacenamiento en caché basado en la expiración para obtener AP, o
+  réplicas y votación mayoritaria para obtener PC —la minoría no está
+  disponible—.
+
+La noción de “dos de tres” en el teorema CAP ha sido criticada por simplificar
+en exceso la relación entre consistencia, disponibilidad y tolerancia a
+particiones. En realidad, las tensiones entre estas propiedades son más
+complejas y matizadas. Si bien CAP señala que no se puede garantizar al mismo
+tiempo consistencia y disponibilidad perfectas durante una partición, estas
+situaciones son poco comunes. Los arquitectos deben seguir eligiendo entre
+consistencia y disponibilidad cuando ocurren particiones, pero tienen mucha
+flexibilidad en la forma de gestionar y recuperarse de ellas. El enfoque actual
+se centra en maximizar las combinaciones más adecuadas para cada aplicación
+específica, incorporando tanto estrategias para operar durante una partición
+como para restaurar el sistema después de superarla. Esta perspectiva amplía el
+entendimiento del teorema CAP, superando las limitaciones que tradicionalmente
+se le atribuían[^2].
+
+[^2]: Brewer, E. (2012). CAP Twelve Years Later: How "Rules" Have Changed. IEEE
+    Computer, vol. 45, no. 2, pp. 23-29, Feb. 2012. Disponible
+    [aquí](https://ieeexplore-ieee-org.proxy.timbo.org.uy/document/6133253) vía
+    Timbó.
+
+### CAP, ACID, BASE
+
+En la práctica la tolerancia a particiones de la red en un sistema distribuido
+no suele ser negociable: las fallas y las divisiones de la red son inevitables
+—y suponer lo contrario es caer en las [falacias de la computación
+distribuida](./4_Falacias_computacion_distribuida.md)—.
+
+Por lo tanto, los arquitectos deben encontrar un equilibrio entre la
+disponibilidad y la consistencia, según sus prioridades. Los sistemas que
+priorizan la disponibilidad sobre la consistencia suelen utilizar modelos de
+consistencia eventual, comunes en el paradigma [BASE](./4_BASE.md), mientras que
+los sistemas que requieren una consistencia sólida se adhieren a los principios
+[ACID](./4_ACID.md).

From 49568ae76f1c655e1fe83e00ba572d6c1cfb6ccf Mon Sep 17 00:00:00 2001
From: Fernando Machado <fmachadopiriz@outlook.com>
Date: Mon, 11 Nov 2024 19:48:54 -0300
Subject: [PATCH 2/3] Added new patterns, work in progress

---
 .../2_8_Patrones_de_diseno.md                 |  0
 2_Tecnicas_y_herramientas/2_9_Cache_aside.md  | 28 ++++++++
 2_Tecnicas_y_herramientas/2_9_Choreography.md | 66 +++++++++++++++++++
 .../2_9_Circuit_breaker.md                    | 40 +++++++++++
 .../2_9_Patrones_de_arquitectura.md           |  0
 .../2_9_Request_Acknowledge.md                | 34 ++++++++++
 .../2_9_Request_Response.md                   | 28 ++++++++
 2_Tecnicas_y_herramientas/2_9_Saga.md         | 33 ++++++++++
 .../2__Tecnicas_y_herramientas.md             |  6 ++
 4_Conceptos/4_BASE.md                         | 22 ++++++-
 .../5_2_4_Soluciones_arquitectonicas.md       |  4 ++
 11 files changed, 260 insertions(+), 1 deletion(-)
 create mode 100644 2_Tecnicas_y_herramientas/2_8_Patrones_de_diseno.md
 create mode 100644 2_Tecnicas_y_herramientas/2_9_Cache_aside.md
 create mode 100644 2_Tecnicas_y_herramientas/2_9_Choreography.md
 create mode 100644 2_Tecnicas_y_herramientas/2_9_Circuit_breaker.md
 create mode 100644 2_Tecnicas_y_herramientas/2_9_Patrones_de_arquitectura.md
 create mode 100644 2_Tecnicas_y_herramientas/2_9_Request_Acknowledge.md
 create mode 100644 2_Tecnicas_y_herramientas/2_9_Request_Response.md
 create mode 100644 2_Tecnicas_y_herramientas/2_9_Saga.md

diff --git a/2_Tecnicas_y_herramientas/2_8_Patrones_de_diseno.md b/2_Tecnicas_y_herramientas/2_8_Patrones_de_diseno.md
new file mode 100644
index 0000000..e69de29
diff --git a/2_Tecnicas_y_herramientas/2_9_Cache_aside.md b/2_Tecnicas_y_herramientas/2_9_Cache_aside.md
new file mode 100644
index 0000000..bc43ae8
--- /dev/null
+++ b/2_Tecnicas_y_herramientas/2_9_Cache_aside.md
@@ -0,0 +1,28 @@
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+       'mainBkg': 'transparent',
+      'primaryColor': 'transparent',
+      'primaryTextColor': '#006EAF',
+      'primaryBorderColor': '#006EAF',
+      'lineColor': '#006EAF',
+      'secondaryColor': '#006100',
+      'fontFamily':'Helvetica',
+      'fontSize':'8px'
+    }
+  }
+}%%
+sequenceDiagram
+    Participant Client
+    Participant Cache
+    Participant Data store
+    Client->>Cache: Petición de datos
+    alt Datos en caché
+    Cache->>Client: Datos pedidos
+    else
+    Cache->>Data store: Petición de datos
+    Cache->>Client: Datos pedidos
+    end
+```
diff --git a/2_Tecnicas_y_herramientas/2_9_Choreography.md b/2_Tecnicas_y_herramientas/2_9_Choreography.md
new file mode 100644
index 0000000..2d1cd31
--- /dev/null
+++ b/2_Tecnicas_y_herramientas/2_9_Choreography.md
@@ -0,0 +1,66 @@
+Con coreografía:
+
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+       'mainBkg': 'transparent',
+      'primaryColor': 'transparent',
+      'primaryTextColor': '#006EAF',
+      'primaryBorderColor': '#006EAF',
+      'lineColor': '#006EAF',
+      'secondaryColor': '#006100',
+      'fontFamily':'Helvetica',
+      'fontSize':'8px'
+    }
+  }
+}%%
+sequenceDiagram
+    Participant Client
+    Participant Orchestrator
+    Participant Service A
+    Participant Service B
+
+    Client->>Orchestrator: Pedido
+    Orchestrator->>Service A: Pedido para A
+    Service A-->>Orchestrator: Respuesta de A
+    Orchestrator->>Service B: Pedido para B
+    Service B-->>Orchestrator: Respuesta de B
+    Orchestrator-->>Client: Respuesta
+```
+
+Con orquestación:
+
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+       'mainBkg': 'transparent',
+      'primaryColor': 'transparent',
+      'primaryTextColor': '#006EAF',
+      'primaryBorderColor': '#006EAF',
+      'lineColor': '#006EAF',
+      'secondaryColor': '#006100',
+      'fontFamily':'Helvetica',
+      'fontSize':'8px'
+    }
+  }
+}%%
+sequenceDiagram
+    Participant Client
+    Participant Orchestrator
+    Participant Service A
+    Participant Service B
+    Participant Service C
+
+    Client->>Orchestrator: Pedido
+    Orchestrator->>Service A: Pedido para A
+    Service A-->>Orchestrator: Respuesta de A
+    Orchestrator->>Service B: Pedido para B
+    Service B-->>Orchestrator: Respuesta de B
+    Orchestrator->>Service C: Pedido para C
+    Service C-->Orchestrator: Respuesta de C
+    Orchestrator-->>Client: Respuesta
+```
\ No newline at end of file
diff --git a/2_Tecnicas_y_herramientas/2_9_Circuit_breaker.md b/2_Tecnicas_y_herramientas/2_9_Circuit_breaker.md
new file mode 100644
index 0000000..f13eda1
--- /dev/null
+++ b/2_Tecnicas_y_herramientas/2_9_Circuit_breaker.md
@@ -0,0 +1,40 @@
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+      'mainBkg': 'transparent',
+      'primaryColor': 'transparent',
+      'primaryTextColor': '#006EAF',
+      'primaryBorderColor': '#006EAF',
+      'lineColor': '#006EAF',
+      'secondaryColor': '#006EAF',
+      'edgeLabelBackground': 'transparent',
+      'fontFamily':'Helvetica',
+      'fontSize':'12px',
+      'noteBkgColor':'transparent',
+      'noteTextColor': '#006EAF',
+      'noteBorderColor':'#006EAF'
+    }
+  }
+}%%
+stateDiagram-v2
+    [*] --> Closed
+    Closed --> Open: Umbral de fallos alcanzado
+    Open --> Half—open: Tiempo de espera expirado
+    Half—open --> Open: Fallo en la operación
+    Half—open --> Closed: Umbral de éxitos alcanzado
+
+    note left of Closed
+        on entry: restablecer contador de errores
+        do: si la operación tiene éxito devolver resultado; sino incrementar contador de errores y devolver error
+    end note
+    note right of Half—open
+        on entry: restablecer contador de éxito
+        do: si la operación tiene éxito incrementar contador de éxito y devolver resultado; sino devolver error
+    end note
+    note left of Open
+        on entry: iniciar temporizador
+        do: retornar error
+    end note
+```
diff --git a/2_Tecnicas_y_herramientas/2_9_Patrones_de_arquitectura.md b/2_Tecnicas_y_herramientas/2_9_Patrones_de_arquitectura.md
new file mode 100644
index 0000000..e69de29
diff --git a/2_Tecnicas_y_herramientas/2_9_Request_Acknowledge.md b/2_Tecnicas_y_herramientas/2_9_Request_Acknowledge.md
new file mode 100644
index 0000000..c5b733a
--- /dev/null
+++ b/2_Tecnicas_y_herramientas/2_9_Request_Acknowledge.md
@@ -0,0 +1,34 @@
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+       'mainBkg': 'transparent',
+      'primaryColor': 'transparent',
+      'primaryTextColor': '#006EAF',
+      'primaryBorderColor': '#006EAF',
+      'lineColor': '#006EAF',
+      'secondaryColor': '#006100',
+      'fontFamily':'Helvetica',
+      'fontSize':'8px'
+    }
+  }
+}%%
+sequenceDiagram
+    Participant Client
+    Participant Service
+    Participant Queue
+    Participant Request processor
+
+    Client->>Service: Pedido
+
+    Service->>Service: [opt] Autenticar, Autorizar, Validar
+
+    Service->>Service: Generar identificador o URI
+    Service->>Queue: Almacenar y reenviar pedido
+    Service-->>Client: Acuse de recibo
+
+    Request processor->>Queue: Obtener pedido
+    Queue-->>Request processor: Pedido
+    Request processor->>Request processor: Procesar pedido
+```
\ No newline at end of file
diff --git a/2_Tecnicas_y_herramientas/2_9_Request_Response.md b/2_Tecnicas_y_herramientas/2_9_Request_Response.md
new file mode 100644
index 0000000..fe33489
--- /dev/null
+++ b/2_Tecnicas_y_herramientas/2_9_Request_Response.md
@@ -0,0 +1,28 @@
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+       'mainBkg': 'transparent',
+      'primaryColor': 'transparent',
+      'primaryTextColor': '#006EAF',
+      'primaryBorderColor': '#006EAF',
+      'lineColor': '#006EAF',
+      'secondaryColor': '#006100',
+      'fontFamily':'Helvetica',
+      'fontSize':'8px',
+      'noteBkgColor':'transparent',
+      'noteTextColor':'#006EAF'
+    }
+  }
+}%%
+sequenceDiagram
+    Participant Client
+    Participant Service
+
+    rect rgba(0, 0, 0, 0.5)
+        note over Client, Service: Conexión
+        Client->>Service: Pedido
+        Service-->>Client: Respuesta
+    end
+```
\ No newline at end of file
diff --git a/2_Tecnicas_y_herramientas/2_9_Saga.md b/2_Tecnicas_y_herramientas/2_9_Saga.md
new file mode 100644
index 0000000..f6e0dd6
--- /dev/null
+++ b/2_Tecnicas_y_herramientas/2_9_Saga.md
@@ -0,0 +1,33 @@
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+       'mainBkg': 'transparent',
+      'primaryColor': 'transparent',
+      'primaryTextColor': '#006EAF',
+      'primaryBorderColor': '#006EAF',
+      'lineColor': '#006EAF',
+      'secondaryColor': '#006100',
+      'fontFamily':'Helvetica',
+      'fontSize':'8px'
+    }
+  }
+}%%
+sequenceDiagram
+    Participant Client
+    Participant Message Broker
+    Participant Service A
+    Participant Service B
+    Participant Service C
+
+    Client->>Message Broker: Pedido
+    Message Broker->>Service A: Pedido para A
+    Service A->>Message Broker: Pedido para B
+    Message Broker->>Service B: Pedido para B
+    Service B->>Message Broker: Pedido para C
+    Message Broker->>Service C: Pedido para C
+    Service C->>Message Broker: Respuesta
+    Message Broker-->>Client: Respuesta
+
+```
\ No newline at end of file
diff --git a/2_Tecnicas_y_herramientas/2__Tecnicas_y_herramientas.md b/2_Tecnicas_y_herramientas/2__Tecnicas_y_herramientas.md
index 4ba8fe9..3664f5f 100644
--- a/2_Tecnicas_y_herramientas/2__Tecnicas_y_herramientas.md
+++ b/2_Tecnicas_y_herramientas/2__Tecnicas_y_herramientas.md
@@ -11,3 +11,9 @@
 ## 2.5 [Tácticas de arquitectura](./2_5_.Tacticas_arquitectura.md)
 
 ## 2.6 [Modelos de proceso](./2_6_.Modelos_de_proceso.md)
+
+## 2.7 [Estilos de arquitectura](./2_7_.Estilos_arquitectura.md)
+
+## 2.8 [Patrones de diseño](./2_8_Patrones_de_diseno.md)
+
+## 2.9 [Patrones de arquitectura](./2_9_Patrones_de_arquitectura.md)
diff --git a/4_Conceptos/4_BASE.md b/4_Conceptos/4_BASE.md
index 87eef2f..abf0075 100644
--- a/4_Conceptos/4_BASE.md
+++ b/4_Conceptos/4_BASE.md
@@ -17,6 +17,8 @@ BASE[^1].
     January 2009, 52(1). Disponible
     [aquí](https://dl.acm.org/doi/pdf/10.1145/1435417.1435432).
 
+https://dl.acm.org/doi/pdf/10.1145/1466443.1466448
+
 BASE en un acrónimo [acrónimo](https://dle.rae.es/acrónimo) que referencia las
 características de este tipo de sistemas: disponibilidad básica —***b**asic
 **a**vailability* en inglés—, estado blando —***s**oft state* en inglés— y
@@ -171,4 +173,22 @@ réplicas.
 
 La forma de configurar N, W y R depende de cuál sea el caso común y qué ruta de rendimiento se necesita optimizar. En R=1 y N=W optimizamos para el caso de lectura, y en W=1 y R=N optimizamos para una escritura muy rápida.
 Por supuesto, en el último caso, la durabilidad no está garantizada en presencia de fallas, y si W < (N+1)/2, existe la posibilidad de escrituras conflictivas cuando los conjuntos de escritura no se superponen.
-La consistencia débil/eventual surge cuando W+R <= N, lo que significa que existe la posibilidad de que el conjunto de lectura y escritura no se superpongan. Si esta es una configuración deliberada y no se basa en un caso de falla, entonces casi no tiene sentido establecer R en algo que no sea 1. Esto sucede en dos casos muy comunes: el primero es la replicación masiva para el escalamiento de lectura mencionado anteriormente; El segundo es donde el acceso a los datos es más complicado. En un modelo clave-valor simple es fácil comparar versiones para determinar el último valor escrito en el sistema, pero en sistemas que devuelven conjuntos de objetos es más difícil determinar cuál debería ser el último conjunto correcto. En la mayoría de estos sistemas donde el conjunto de escritura es más pequeño que el conjunto de réplicas, existe un mecanismo que aplica las actualizaciones de manera diferida a los nodos restantes en el conjunto de la réplica. El período hasta que se hayan actualizado todas las réplicas es la ventana de inconsistencia discutida anteriormente. Si W+R <= N, entonces el sistema es vulnerable a la lectura de nodos que aún no han recibido las actualizaciones.
\ No newline at end of file
+La consistencia débil/eventual surge cuando W+R <= N, lo que significa que
+existe la posibilidad de que el conjunto de lectura y escritura no se
+superpongan. Si esta es una configuración deliberada y no se basa en un caso de
+falla, entonces casi no tiene sentido establecer R en algo que no sea 1. Esto
+sucede en dos casos muy comunes: el primero es la replicación masiva para el
+escalamiento de lectura mencionado anteriormente; El segundo es donde el acceso
+a los datos es más complicado. En un modelo clave-valor simple es fácil comparar
+versiones para determinar el último valor escrito en el sistema, pero en
+sistemas que devuelven conjuntos de objetos es más difícil determinar cuál
+debería ser el último conjunto correcto. En la mayoría de estos sistemas donde
+el conjunto de escritura es más pequeño que el conjunto de réplicas, existe un
+mecanismo que aplica las actualizaciones de manera diferida a los nodos
+restantes en el conjunto de la réplica. El período hasta que se hayan
+actualizado todas las réplicas es la ventana de inconsistencia discutida
+anteriormente. Si W+R <= N, entonces el sistema es vulnerable a la lectura de
+nodos que aún no han recibido las actualizaciones.
+
+Ver también
+https://learn.microsoft.com/en-us/previous-versions/msp-n-p/dn589800(v=pandp.10)
diff --git a/5_Unidades_tematicas/5_2_4_Soluciones_arquitectonicas.md b/5_Unidades_tematicas/5_2_4_Soluciones_arquitectonicas.md
index f7eee67..02998d5 100644
--- a/5_Unidades_tematicas/5_2_4_Soluciones_arquitectonicas.md
+++ b/5_Unidades_tematicas/5_2_4_Soluciones_arquitectonicas.md
@@ -15,6 +15,10 @@
 
 * [Interacción](/4_Conceptos/4_Interaccion.md)
 
+* Virtualización
+
+* ACID, BASE, CAP
+
 <!-- TBD. Incluir la parte III de Bass
 Virtualización
 Computación en la nube y distribuida

From c3fe4cbdb49614576c577fab2e07669d69b3b19a Mon Sep 17 00:00:00 2001
From: Fernando Machado <fmachadopiriz@outlook.com>
Date: Tue, 24 Dec 2024 13:48:00 -0300
Subject: [PATCH 3/3] Added new entries

---
 4_Conceptos/4_.Conceptos.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/4_Conceptos/4_.Conceptos.md b/4_Conceptos/4_.Conceptos.md
index dd7dd5f..c5c1cf3 100644
--- a/4_Conceptos/4_.Conceptos.md
+++ b/4_Conceptos/4_.Conceptos.md
@@ -1,5 +1,7 @@
 # 4 Conceptos
 
+## [ACID](./4_ACID.md)
+
 ## [Acoplamiento](./4_Acoplamiento.md)
 
 ## [ADR](./4_ADR.md)
@@ -8,8 +10,12 @@
 
 ## [Atributos de calidad](./4_Atributos_de_calidad.md)
 
+## [BASE](./4_BASE.md)
+
 ## [Calidad de software](./4_Calidad_de_software.md)
 
+## [CAP](./4_CAP.md)
+
 ## [Características arquitectónicas](./4_Caracteristicas_arquitectonicas.md)
 
 ## [Caso de uso del negocio](./4_Caso_de_uso_del_negocio.md)