Be Wise Apps
Read in English · Lire en français · Auf Deutsch lesen
Sección 2.7 de 2.8 · Intermedio · 22 min de lectura
Seguridad, usabilidad, interoperabilidad, costo y sostenibilidad como cualidades
Videolección
5 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
Esta lección trata las cualidades restantes: la seguridad, la usabilidad, la interoperabilidad, el costo, la sostenibilidad y algunas más que es fácil pasar por alto hasta que llega una auditoría.
Cuando eliges un banco, te importa que mantenga tu dinero a salvo, que su app sea fácil de usar, que funcione con otros bancos, que sus comisiones sean justas y, quizá, que no desperdicie energía. Ninguna de estas cosas es una funcionalidad que puedas señalar en una pantalla. Cada una es una cualidad del servicio en su conjunto, y los arquitectos deben concretar cada una lo suficiente como para diseñar en función de ella y comprobarla.
La seguridad es la capacidad de proteger los datos y las funciones frente al uso no autorizado, sin dejar de dar servicio a quienes sí están autorizados. El estándar internacional enumera seis subcaracterísticas. La confidencialidad significa que solo las partes autorizadas pueden leer los datos. La integridad significa que los datos y el código no se alteran sin autorización. Estas dos proceden de la clásica tríada CIA. El no repudio significa que las acciones no se pueden negar después. La responsabilidad significa que se pueden atribuir a quien las realizó. La autenticidad significa que se puede demostrar una identidad. Y la resistencia, novedad de dos mil veintitrés, significa que el sistema sigue funcionando mientras sufre un ataque. La A de la tríada, la disponibilidad, está dentro de la fiabilidad en este modelo.
"El sistema debe ser seguro" no se puede probar. Un escenario de seguridad nombra al atacante, el ataque, el objetivo y una medida. Por ejemplo, un atacante prueba contraseñas filtradas a cincuenta intentos por segundo. El sistema detecta el patrón en menos de dos minutos y exige una verificación adicional a los orígenes o los bloquea. Las tácticas de seguridad actúan en momentos distintos. Antes de un ataque, resístelo: autentica, autoriza, limita la exposición, cifra y valida la entrada. Durante un ataque, detéctalo y luego reacciona: revoca el acceso, bloquea cuentas, corta el tráfico y da la alerta. Después, recupérate desde copias de seguridad limpias y usa la pista de auditoría para saber qué ocurrió. La seguridad es una propiedad de toda la estructura, no un componente que se añade al final.
La usabilidad, que ahora se llama capacidad de interacción, es sobre todo diseño de interacción, pero una parte llega hasta lo más profundo de la estructura. La capacidad de respuesta es una de ellas. Alrededor de una décima de segundo se percibe como instantáneo, alrededor de un segundo mantiene tu hilo de pensamiento y unos diez segundos son el límite de la atención. Deshacer, cancelar y trabajar sin conexión también son cuestiones arquitectónicas. Es mucho más barato incorporarlos en el diseño que añadirlos a posteriori. La accesibilidad es cada vez más una restricción legal. Las pautas de accesibilidad para el contenido web, versión dos punto dos, definen criterios comprobables, y el nivel doble A es la referencia habitual. En la Unión Europea, el Acta Europea de Accesibilidad se aplica desde el veintiocho de junio de dos mil veinticinco a muchos servicios, como la banca y las tiendas en línea. Así que recógela pronto.
La interoperabilidad significa que los sistemas pueden intercambiar información y usarla. No basta con ponerse de acuerdo en el formato; tienen que ponerse de acuerdo en el significado. ¿Un importe de mil cincuenta está en peniques o en libras? La mayoría de los fallos de integración tienen que ver con el significado. La seguridad frente a daños, la safety, es distinta de la seguridad frente a ataques. La seguridad frente a ataques protege el sistema de las personas con intenciones dañinas. La safety protege a las personas del sistema, incluso cuando nadie actúa con malicia. La observabilidad es lo bien que puedes entender qué falla a partir de los datos que emite un sistema. El tiempo de recuperación, y por tanto la disponibilidad, depende de ella. Y las leyes también crean cualidades: dónde se almacenan los datos, cómo se demuestra quién hizo qué y cuándo, y cuánto tiempo se conservan los datos. Trátalas como restricciones con criterios de aceptación claros.
El costo y el carbono se miden mejor por unidad de trabajo. Un servicio de pedidos cuesta veinticuatro mil libras al mes y gestiona tres millones de pedidos. Eso son cero punto ocho peniques por pedido. Para el carbono, la fórmula de Software Carbon Intensity multiplica la energía por la intensidad de carbono de la electricidad. Mil doscientos kilovatios hora a doscientos cincuenta gramos cada uno son trescientos kilogramos. Suma sesenta kilogramos por las emisiones de fabricar el hardware: trescientos sesenta kilogramos. Divide entre tres millones de pedidos y obtienes cero punto doce gramos de dióxido de carbono equivalente por pedido. Almacenar las cartas en caché para reducir la energía un veinticinco por ciento lo baja a cero punto cero noventa y cinco gramos por pedido. Solo cuentan las reducciones reales. Comprar compensaciones de carbono no reduce la puntuación. Y como ambas medidas son por pedido, premian la eficiencia en lugar de penalizar el crecimiento.
La sección completa incluye más escenarios de seguridad, los estándares de interoperabilidad y de safety, y una tabla resumen con medidas de ejemplo. A continuación, en la Sección dos punto ocho, la última de este capítulo, veremos cómo encontrar, clasificar y equilibrar las cualidades. Nos vemos allí.
Lo que necesitas saber
- La seguridad parte de la confidencialidad, la integridad y la disponibilidad; ISO/IEC 25010:2023 enumera la confidencialidad, la integridad, el no repudio, la responsabilidad, la autenticidad y la resistencia, y sitúa la disponibilidad dentro de la fiabilidad.
- Los escenarios de seguridad nombran al atacante, el ataque, el objetivo y una respuesta medible, como el tiempo de detección o los datos expuestos; las tácticas resisten los ataques, los detectan, reaccionan ante ellos y permiten recuperarse.
- La capacidad de interacción (antes llamada usabilidad) afecta a la arquitectura a través de la capacidad de respuesta, deshacer, cancelar y el trabajo sin conexión; la accesibilidad conforme al nivel AA de WCAG 2.2 es cada vez más una restricción legal.
- La interoperabilidad exige acuerdo sobre el significado, no solo sobre el formato; los estándares del sector y los adaptadores reducen el costo.
- El costo y el carbono se expresan mejor por unidad de trabajo; la especificación SCI (ISO/IEC 21031:2024) calcula ((E x I) + M) por R y solo cuenta las reducciones reales.
- La seguridad (safety), la observabilidad, la residencia de datos, la auditabilidad y la conservación de datos también son cualidades, y deben recogerse pronto como restricciones que se puedan probar.
La seguridad como atributo de calidad
La seguridad es la capacidad del sistema de proteger los datos y las funciones frente al acceso y el uso no autorizados sin dejar de dar servicio a quienes sí están autorizados. Los arquitectos suelen partir de la tríada CIA: confidencialidad (solo las partes autorizadas pueden leer los datos), integridad (los datos y el código no se alteran sin autorización, y las alteraciones se pueden detectar) y disponibilidad (los usuarios autorizados pueden usar el servicio cuando lo necesitan). Los ataques se corresponden con las tres: robar registros de clientes vulnera la confidencialidad, cambiar los datos bancarios de un beneficiario vulnera la integridad y un ataque de denegación de servicio vulnera la disponibilidad.
ISO/IEC 25010:2023 afina el panorama. Su característica de seguridad tiene seis subcaracterísticas: confidencialidad, integridad, no repudio (se puede demostrar que las acciones o los eventos han tenido lugar, de modo que una parte no pueda negarlos después), responsabilidad (accountability: las acciones se pueden atribuir de forma inequívoca a la entidad que las realizó), autenticidad (se puede demostrar que la identidad de un sujeto o de un recurso es la que dice ser) y, como novedad de la edición de 2023, resistencia (el producto sigue funcionando como está previsto mientras sufre el ataque de un actor malicioso). En ese modelo, la disponibilidad aparece dentro de la fiabilidad, y por eso se trató en la Sección 2.5.
Las subcaracterísticas de seguridad
Escribir escenarios de seguridad
"El sistema debe ser seguro" no se puede diseñar ni probar. Un escenario de seguridad nombra una fuente (quién ataca y con qué acceso), un estímulo (qué intenta), un artefacto (qué es el objetivo), un entorno (en línea, durante un incidente, con el atacante ya dentro de la red), una respuesta y una medida. Las medidas de seguridad suelen referirse al tiempo de detección, a la cantidad de daño o al tiempo de restauración, porque "ningún ataque tiene éxito nunca" no se puede verificar.
Tres ejemplos para un banco en línea. Relleno de credenciales (credential stuffing): un atacante externo prueba pares filtrados de nombre de usuario y contraseña contra la API de inicio de sesión, a 50 intentos por segundo y desde muchas direcciones; el sistema detecta el patrón en menos de 2 minutos, exige una verificación adicional a las direcciones de origen o las bloquea, y no se toma el control de las cuentas protegidas con autenticación multifactor. Manipulación interna: un empleado de soporte con acceso legítimo cambia los datos del beneficiario de un cliente; el cambio requiere la aprobación de una segunda persona, y el registro de auditoría guarda quién, qué y cuándo de una forma que el empleado no puede alterar. Copia de seguridad robada: un atacante obtiene una copia de la copia de seguridad de la base de datos de la semana pasada; todos los datos personales que contiene están cifrados con claves guardadas por separado, así que no se puede leer ningún dato de clientes.
Observa que cada escenario implica una arquitectura distinta: limitación de tasa (rate limiting) y detección de anomalías en el perímetro; un flujo de aprobación por cuatro ojos y registros a prueba de manipulaciones; y cifrado con una gestión de claves separada. Encontrar estos escenarios de forma sistemática es la tarea del modelado de amenazas, que se trata en el Capítulo 8.
Tácticas de seguridad: una visión general
Bass, Clements y Kazman agrupan las tácticas de seguridad según el momento en que actúan. Resistir los ataques: identificar, autenticar y autorizar a los actores; limitar el acceso y la exposición (menos puertos abiertos, menos endpoints públicos, mínimo privilegio); cifrar los datos en tránsito y en reposo; separar entidades (los datos sensibles en su propio almacén o segmento de red); cambiar la configuración predeterminada y validar la entrada. Detectar los ataques: detección de intrusiones, detección de la denegación de servicio, verificación de la integridad de los mensajes y localización de retrasos o patrones inusuales. Reaccionar ante los ataques: revocar el acceso, bloquear cuentas tras varios inicios de sesión fallidos, informar a los operadores y a los usuarios. Recuperarse de los ataques: restaurar un estado correcto conocido (de nuevo, las tácticas de disponibilidad) y mantener una pista de auditoría para entender qué ocurrió y respaldar el no repudio.
Esta sección solo presenta las familias. Principios como la defensa en profundidad y el mínimo privilegio, los protocolos de identidad, el cifrado, zero trust y la seguridad de la cadena de suministro son el tema del Capítulo 8. Lo que importa aquí desde el punto de vista arquitectónico es que la seguridad es una propiedad de toda la estructura, no un componente que se añade al final: dónde se sitúan los límites de confianza, qué componente guarda qué datos y cómo se autentican los servicios entre sí son decisiones tempranas y costosas de cambiar.
Tácticas antes, durante y después de un ataque
Usabilidad, capacidad de interacción y accesibilidad
ISO/IEC 25010:2023 cambió el nombre de la usabilidad por el de capacidad de interacción: el grado en que usuarios especificados pueden interactuar con un producto para intercambiar información a través de la interfaz de usuario y completar tareas concretas. Sus subcaracterísticas son la reconocibilidad de la adecuación, la capacidad de aprendizaje, la operabilidad, la protección contra errores del usuario, la implicación del usuario (que sustituyó a la estética de la interfaz de usuario), la inclusividad, la asistencia al usuario y la autodescriptividad. Gran parte de esto es diseño de interacción más que arquitectura, pero varias inquietudes de usabilidad llegan hasta lo más profundo de la estructura.
La capacidad de respuesta es la más evidente. Las pautas de factores humanos, establecidas desde hace mucho y popularizadas por Jakob Nielsen, dan tres límites: unos 0.1 segundos se perciben como instantáneos, alrededor de 1 segundo mantiene el hilo de pensamiento del usuario y unos 10 segundos son el límite de la atención. Cumplirlos puede exigir caché, procesamiento asíncrono con indicación del progreso o actualizaciones optimistas. Deshacer y cancelar son cuestiones arquitectónicas: admitir deshacer las cinco últimas acciones
requiere comandos que se puedan revertir, y cancelar una subida larga requiere una operación que se pueda interrumpir limpiamente. Trabajar sin conexión en una app para dispositivos móviles requiere almacenamiento local y sincronización con gestión de conflictos. Todo esto es mucho más barato de incorporar en el diseño que de añadir a posteriori.
La accesibilidad, es decir, la capacidad de las personas con discapacidad de usar el producto, es cada vez más una restricción legal y no una preferencia. Las Web Content Accessibility Guidelines (pautas de accesibilidad para el contenido web) versión 2.2 (WCAG 2.2), Recomendación del W3C desde octubre de 2023, definen criterios de conformidad comprobables en los niveles A, AA y AAA; el nivel AA es la referencia habitual en el ámbito legal y en la contratación. WCAG 2.2 añadió nueve criterios, entre ellos un tamaño mínimo de los objetivos para la entrada con puntero y la autenticación accesible (ningún paso del inicio de sesión puede depender de una prueba de función cognitiva, como recordar una contraseña o transcribir un código, salvo que se ofrezca al usuario un método alternativo o una ayuda, como pegar desde un gestor de contraseñas; hay además unas pocas excepciones concretas). En la Unión Europea, el Acta Europea de Accesibilidad (Directiva (UE) 2019/882) se aplica desde el 28 de junio de 2025 a muchos productos y servicios de consumo, como el comercio electrónico, los servicios bancarios, los libros electrónicos y los servicios de transporte de pasajeros. Para un arquitecto, la accesibilidad es, por tanto, una restricción que hay que recoger pronto: afecta a la elección del framework de frontend, al sistema de diseño, al flujo de autenticación y al pipeline de pruebas (comprobaciones automáticas de accesibilidad en la integración continua, además de pruebas manuales con tecnologías de apoyo).
Interoperabilidad
La interoperabilidad es el grado en que dos o más sistemas pueden intercambiar información y usar la información que intercambian. ISO/IEC 25010 la sitúa dentro de la compatibilidad, junto a la coexistencia. Tiene dos niveles. La interoperabilidad sintáctica significa que los sistemas se ponen de acuerdo en el formato y el protocolo: ambos hablan HTTP y JSON. La interoperabilidad semántica significa que se ponen de acuerdo en el significado: "amount": 1050 está en peniques, no en libras; status: "closed" significa pagado, no cancelado. La mayoría de los fallos de integración son semánticos.
Los sectores reducen el costo del acuerdo semántico con estándares compartidos: HL7 FHIR para intercambiar historias clínicas, ISO 20022 para los mensajes financieros, GTFS para los horarios del transporte público. Entre las tácticas arquitectónicas están descubrir los servicios a través de un registro, adaptar las interfaces con adaptadores y traductores, y gestionar las versiones de forma explícita para que los socios más antiguos sigan funcionando. Un escenario de interoperabilidad podría decir: Un nuevo hospital se une a la red e intercambia resúmenes de pacientes con recursos FHIR R4 en un plazo de 4 semanas, sin cambios en el servicio central de historias clínicas.
El costo como cualidad
El costo rara vez figura en los modelos de calidad, pero condiciona todas las decisiones arquitectónicas. Distingue el costo de construcción (el esfuerzo de crear el sistema), el costo de operación (infraestructura, licencias, servicios de terceros, soporte) y el costo de cambio (el esfuerzo de cada cambio futuro, que es de lo que trata la modificabilidad). En la nube, el costo de operación es variable y depende directamente de la arquitectura: los servicios que se comunican en exceso pagan por la transferencia de red, los clústeres sobredimensionados pagan por capacidad ociosa y un patrón de consultas descuidado puede multiplicar la factura de una base de datos.
Una forma útil de convertir el costo en un atributo de calidad es el costo unitario: el costo por transacción, por usuario activo o por pedido. A diferencia de una factura mensual total, muestra si la arquitectura se vuelve más o menos eficiente a medida que crece el negocio, y se puede escribir como escenario: Con 3 millones de pedidos al mes, el costo de infraestructura se mantiene por debajo de 1 penique por pedido.
Las prácticas de FinOps para gestionarlo se tratan en el Capítulo 10.
Ejemplo práctico
Ejemplo práctico: costo unitario y carbono por solicitud en una API de reparto de comida
Una API de pedidos se ejecuta en un clúster que cuesta £24 000 al mes y gestiona 3 000 000 de pedidos al mes. Un análisis estima su consumo de energía en 1200 kWh al mes, en una red eléctrica con una media de 250 g de CO2e por kWh, y se le asignan cada mes 60 kg de CO2e de emisiones incorporadas del hardware. La fórmula de Software Carbon Intensity es SCI = ((E x I) + M) por R.
| Costo por pedido | £24 000 / 3 000 000 = £0.008, es decir, 0.8 peniques por pedido |
|---|---|
| Emisiones operativas (E x I) | 1200 kWh x 250 g = 300 000 g = 300 kg de CO2e |
| Sumar las emisiones incorporadas (M) | 300 + 60 = 360 kg de CO2e |
| Dividir entre la unidad funcional (R = un pedido) | 360 000 g / 3 000 000 = 0.12 g de CO2e por pedido |
| Cambio: almacenar las cartas en caché, reducir la energía un 25% | E = 900 kWh: (900 x 250 + 60 000) / 3 000 000 = 0.095 g por pedido |
| Cambio: ejecutar los trabajos por lotes en una región con 50 g por kWh | Reduce I para esa parte de la carga; la planificación consciente del carbono reduce la puntuación sin cambiar el código |
| Crecimiento hasta 6 000 000 de pedidos en el mismo clúster | El costo por pedido se reduce a la mitad, a 0.4 peniques; el carbono por pedido también baja, siempre que la energía crezca menos que proporcionalmente (los servidores ociosos siguen consumiendo electricidad, así que una mayor utilización es más eficiente) |
Ambas métricas son tasas por unidad de trabajo útil, así que premian la eficiencia en lugar de penalizar el crecimiento.
La especificación SCI solo cuenta las reducciones reales: comprar compensaciones de carbono o certificados de energía renovable no reduce la puntuación.
Las cifras de energía y de la red eléctrica son estimaciones; lo que importa es medirlas siempre de la misma manera para poder comparar los cambios.
Eficiencia energética y sostenibilidad
El software no emite carbono por sí mismo, pero el hardware en el que se ejecuta consume electricidad e incorpora las emisiones de su fabricación. La especificación Software Carbon Intensity (SCI) de la Green Software Foundation, publicada por ISO como ISO/IEC 21031:2024, define una tasa: las emisiones operativas (la energía E multiplicada por la intensidad de carbono I de la electricidad) más las emisiones incorporadas M, divididas entre una unidad funcional R, como un usuario, una llamada a la API o un pedido. Identifica tres palancas: la eficiencia energética (usar menos electricidad para el mismo trabajo), la eficiencia del hardware (usar menos dispositivos y aprovecharlos más y durante más tiempo) y la conciencia del carbono (ejecutar el trabajo flexible cuando y donde la electricidad es más limpia).
La arquitectura influye en las tres. El ajuste del tamaño de los recursos (right-sizing) y una mayor utilización mejoran la eficiencia del hardware; la caché, los formatos de datos eficientes y evitar el trabajo innecesario mejoran la eficiencia energética; las colas y el procesamiento por lotes permiten desplazar el trabajo en el tiempo o en el espacio. La sostenibilidad suele ir de la mano del costo, pero no siempre: mantener una réplica en espera activa (warm standby) en una segunda región mejora la disponibilidad y duplica las emisiones incorporadas. Los grandes modelos de IA hacen la cuestión más acuciante, como explica el Capítulo 12.
Seguridad (safety)
La seguridad (safety) es la ausencia de un riesgo inaceptable de daño a las personas, los bienes o el medio ambiente. Se distingue de la seguridad frente a ataques (security): esta protege el sistema de las personas con intenciones dañinas; la safety protege a las personas del sistema, incluso cuando nadie actúa con malicia. ISO/IEC 25010:2023 añadió la safety como novena característica, con las subcaracterísticas restricción operativa, identificación de riesgos, a prueba de fallos (fail safe), advertencia de peligro e integración segura.
Los ámbitos críticos para la seguridad (safety) tienen sus propios estándares, que imponen arquitectura y procesos: IEC 61508 para la seguridad funcional en general, ISO 26262 para los vehículos de carretera, IEC 62304 para el software de dispositivos médicos y DO-178C para el software embarcado en aeronaves. Las tácticas típicas son un comportamiento predeterminado a prueba de fallos (un tren se detiene cuando pierde las señales), canales de monitorización independientes que pueden anular al controlador principal, redundancia con votación y una separación estricta entre los componentes críticos para la seguridad y todo lo demás, para que un defecto en el sistema de infoentretenimiento no pueda llegar a los frenos. Ten en cuenta que "a prueba de fallos" y "altamente disponible" pueden entrar en conflicto: un sistema a prueba de fallos a menudo se detiene, lo cual es seguro pero no está disponible.
La observabilidad, una cualidad emergente
La observabilidad es el grado en que puedes entender el estado interno de un sistema desde fuera, a partir de los datos que emite, lo bastante bien como para responder preguntas que no se previeron cuando se construyó. No figura en ISO/IEC 25010, aunque la analizabilidad y la responsabilidad se acercan a ella. En los sistemas distribuidos se ha convertido en una cualidad por derecho propio, porque el tiempo de recuperación, y por tanto la disponibilidad, depende de lo rápido que las personas puedan averiguar qué falla. Desde el punto de vista arquitectónico requiere logs estructurados, métricas y trazas distribuidas con identificadores de correlación que sigan a una solicitud a través de los servicios, diseñados desde el principio. Un escenario podría ser: Ante cualquier pago fallido, un ingeniero de guardia puede identificar el servicio que falla y el recorrido de la solicitud en menos de 5 minutos.
Consulta la observabilidad en el Capítulo 9.
Cualidades legales y regulatorias
Las leyes y la normativa crean cualidades que es fácil pasar por alto hasta que llega una auditoría. La residencia de datos exige que ciertos datos se almacenen o se procesen en un país o una región concretos; puede venir de normas sectoriales, de contratos del sector público o de exigencias de los clientes. El RGPD (GDPR) de la UE no exige por sí mismo que los datos permanezcan en la UE, pero las transferencias fuera de ella necesitan una base jurídica y garantías, lo que en la práctica determina dónde se ejecutan los servicios y las copias de seguridad. La auditabilidad significa poder mostrar, más adelante, quién hizo qué y cuándo: registros a prueba de manipulaciones, conservados durante un periodo definido y con los relojes sincronizados. Las normas de conservación y eliminación exigen que los datos se conserven durante un tiempo mínimo (registros financieros) y se eliminen tras un tiempo máximo o cuando se solicite (datos personales), lo que resulta difícil en sistemas con muchas copias, cachés y copias de seguridad. La explicabilidad y la supervisión humana se exigen para algunas decisiones automatizadas, como explica el capítulo sobre el Reglamento de IA de la UE.
Trátalas como restricciones con criterios de aceptación: "los datos de los clientes alemanes del sector público se almacenan y procesan solo en regiones de la UE, incluidas las copias de seguridad y los logs" se puede probar, y descarta de inmediato algunos servicios gestionados. Los requisitos de privacidad se tratan en privacidad desde el diseño y el RGPD.
Resumen: las cualidades de esta sección y medidas de ejemplo
| Calidad | Medida de la respuesta de ejemplo | Palanca arquitectónica típica |
|---|---|---|
| Seguridad (confidencialidad) | Ningún dato personal legible a partir de una copia de seguridad robada | Cifrado en reposo con claves gestionadas por separado |
| Seguridad (responsabilidad) | Cada cambio en los datos de un beneficiario atribuible a una persona, registros a prueba de manipulaciones | Registro de auditoría central, almacenamiento de escritura única |
| Capacidad de interacción | El 95% de los usuarios nuevos completa el pago sin ayuda en menos de 3 minutos | Flujos sencillos, respuestas rápidas, deshacer |
| Accesibilidad | Todos los recorridos del cliente cumplen el nivel AA de WCAG 2.2 | Sistema de diseño accesible, comprobaciones automáticas en CI |
| Interoperabilidad | Nuevo socio integrado con el estándar de API publicado en un plazo de 4 semanas | Formatos estándar, adaptadores, API versionadas |
| Costo | Infraestructura por debajo de 1 penique por pedido con 3 millones de pedidos al mes | Ajuste del tamaño (right-sizing), caché, autoescalado |
| Sostenibilidad | SCI por debajo de 0.1 g de CO2e por pedido | Eficiencia, utilización, planificación consciente del carbono |
| Observabilidad | Servicio que falla identificado en menos de 5 minutos para cualquier solicitud fallida | Logs estructurados, métricas, trazado distribuido |
| Residencia de datos | Todos los datos de los clientes de la UE, incluidas las copias de seguridad, permanecen en regiones de la UE | Almacenamiento y procesamiento fijados a una región |
Comprueba lo que has entendido
¿Cuál es la diferencia entre la responsabilidad y el no repudio?
La responsabilidad significa que las acciones se pueden atribuir a la entidad que las realizó; el no repudio significa que hay una prueba lo bastante sólida como para que la entidad no pueda negar después la acción.
¿Por qué "deshacer las cinco últimas acciones" cuenta como un requisito arquitectónico y no solo de la interfaz de usuario?
Porque exige modelar las operaciones como comandos reversibles con un historial almacenado, lo que afecta a cómo se estructuran los cambios de estado en todo el sistema.
Una API consume 800 kWh al mes en una red eléctrica con 200 g de CO2e por kWh, tiene asignados 40 kg de emisiones incorporadas y atiende 2 000 000 de solicitudes. ¿Cuál es su SCI por solicitud?
(800 x 200 g + 40 000 g) / 2 000 000 = 200 000 / 2 000 000 = 0.1 g de CO2e por solicitud.
¿En qué se diferencia la seguridad (safety) de la seguridad frente a ataques (security)?
La security protege el sistema y sus datos de las personas con intenciones dañinas; la safety protege a las personas y el medio ambiente del daño que el sistema podría causar, incluso sin ningún actor malicioso.
Fuentes y lecturas recomendadas
¿Tienes una pregunta sobre esta sección? ArchitectBot, el asistente de estudio con IA del curso, responde primero a partir del curso.
Pregunta: “¿Cómo escribo un requisito de seguridad para el portal de clientes que los testers puedan verificar de verdad?”