### Diferencias entre arquitecturas cliente-servidor y peer-to-peer (P2P)
1. **Cliente-Servidor**:
- **Descripción**: El servidor actúa como un proveedor centralizado de recursos y servicios; los
clientes solicitan dichos recursos.
- **Comunicación**: Generalmente, un cliente se comunica con un servidor para realizar
operaciones, mientras que el servidor gestiona las solicitudes de múltiples clientes.
- **Ejemplo**: Aplicaciones web tradicionales como Gmail o un servidor FTP.
- **Ventajas**:
- Control centralizado facilita la administración.
- Seguridad más manejable debido a la centralización.
- **Desventajas**:
- Punto único de fallo.
- Escalabilidad limitada sin infraestructura adecuada.
2. **Peer-to-Peer (P2P)**:
- **Descripción**: No hay un servidor centralizado. Cada nodo actúa como cliente y servidor
simultáneamente.
- **Comunicación**: Los nodos comparten recursos directamente entre sí.
- **Ejemplo**: Redes de intercambio de archivos como BitTorrent.
- **Ventajas**:
- Escalabilidad natural debido a la descentralización.
- Mayor resistencia a fallos.
- **Desventajas**:
- Menor control centralizado.
- Seguridad y manejo de datos más complejos.
---
### Comunicación entre procesos en sistemas distribuidos
- **Implementación**:
- La comunicación entre procesos en sistemas distribuidos se realiza mediante mecanismos
como llamadas a procedimientos remotos (RPC), mensajes o colas de mensajes.
- En muchos casos, se usan middleware como CORBA, gRPC o AMQP para facilitar la interacción.
- **Protocolos comunes**:
1. **HTTP/HTTPS**: Utilizado para REST APIs.
2. **Protocolo de Transferencia de Mensajes MQ** (Message Queue Protocol): Utilizado en
sistemas de mensajería asíncrona como RabbitMQ.
---
### Ventajas y desventajas de los microservicios frente a la arquitectura monolítica
1. **Microservicios**:
- **Ventajas**:
- Escalabilidad independiente de componentes.
- Facilita la implementación de tecnologías heterogéneas.
- Mayor agilidad en el desarrollo y despliegue.
- **Desventajas**:
- Complejidad en la gestión de comunicación entre servicios.
- Mayor costo en términos de recursos e infraestructura.
2. **Arquitectura monolítica**:
- **Ventajas**:
- Facilidad en la implementación inicial.
- Menos dependencia de herramientas externas.
- **Desventajas**:
- Dificultad para escalar componentes específicos.
- Menor flexibilidad en actualizaciones.
---
### Consistencia eventual en sistemas distribuidos
1. **Concepto**:
- En un sistema de consistencia eventual, los datos no están necesariamente sincronizados en
todos los nodos en un momento dado, pero eventualmente alcanzarán un estado consistente si
no se producen más actualizaciones.
2. **Beneficios**:
- Mejor rendimiento y escalabilidad.
- Adecuado para aplicaciones que toleran latencias.
3. **Desafíos**:
- Manejo de conflictos de datos.
- Garantizar la experiencia del usuario cuando los datos no son consistentes.
4. **Comparación con consistencia estricta**:
- **Consistencia estricta**: Garantiza que todas las operaciones vean los mismos datos al
mismo tiempo, pero con un mayor costo en términos de rendimiento.
- **Consistencia eventual**: Relaja estas garantías para mejorar la disponibilidad y el
rendimiento.
---
### Arquitectura de un sistema distribuido basado en la nube
1. **Componentes clave**:
- **Frontend**: Interfaz para los usuarios.
- **Backend**: APIs y lógica de negocio.
- **Base de datos**: Almacenamiento distribuido.
- **Servicios de orquestación**: Kubernetes, Docker Swarm.
2. **Escalabilidad**:
- Uso de balanceadores de carga para distribuir el tráfico.
- Recursos elásticos, como autoescalado en AWS EC2 o Google Cloud Compute Engine.
3. **Tolerancia a fallos**:
- Replicación de datos.
- Despliegue en múltiples zonas de disponibilidad.
- Monitoreo continuo para detección de fallos.
