Verificación de conocimientos - Integración de servicios
Un desarrollador está configurando la API de TaskBoard para conectarla con su clúster de IONOS CLOUD PostgreSQL. Construye la cadena de conexión a partir de la salida de Terraform y establece explícitamente sslmode=disable porque la aplicación se ejecuta dentro del mismo VDC. Las conexiones siguen negociando TLS independientemente de esta configuración. ¿Qué explica este comportamiento?
IONOS CLOUD PostgreSQL utiliza un modo SSL de prefer que el cliente no puede desactivar, por lo que el cifrado en tránsito se aplica independientemente de la solicitud de sslmode=disable de la aplicación. Las opciones de distracción sobre el controlador y la salida de Terraform son incorrectas porque el comportamiento es una política del lado del servidor del clúster administrado, no un artefacto de una biblioteca de cliente o de una herramienta.
La interfaz de usuario del navegador de TaskBoard debe permitir a los usuarios cargar archivos adjuntos de gran tamaño directamente en IONOS CLOUD Object Storage, sin que el servidor de API actúe como proxy de los bytes. ¿Qué enfoque de boto3 implementa correctamente esto contra IONOS CLOUD Object Storage?
IONOS CLOUD Object Storage expone la API de AWS S3 y autentica mediante una Access Key y una Secret Key, por lo que boto3 debe recibir un endpoint_url explícito junto con esas credenciales. Las URLs prefirmadas permiten que el navegador realice la carga sin que la API toque los bytes. Los tokens Bearer y los roles IAM no autentican Object Storage, y NFS es un producto de almacenamiento separado y no relacionado.
Un desarrollador agrega un consumidor de Kafka al worker de TaskBoard para que pueda reaccionar a eventos de cambio de tareas. La conexión desde el código de la aplicación utilizando solo un nombre de usuario y una contraseña no logra autenticarse contra el plano de datos de IONOS CLOUD Kafka. ¿Qué requiere una configuración de cliente correcta?
El plano de datos de IONOS CLOUD Kafka autentica a los clientes mediante TLS mutuo, por lo que el consumidor debe presentar un certificado de cliente a través de una conexión cifrada. El token Bearer se aplica únicamente a la API de gestión, el texto plano nunca se acepta, y las credenciales de Access Key y Secret Key corresponden a Object Storage, no a Kafka.
TaskBoard utiliza IONOS CLOUD In-Memory DB (Redis) como caché de sesión y de lectura para escalar las lecturas, ya que el clúster de PostgreSQL no tiene réplicas de lectura para descargar ese tráfico. Bajo carga sostenida, la caché se llena hasta su límite de memoria. Con la configuración predeterminada, ¿qué ocurre con las nuevas escrituras una vez que la memoria está llena?
IONOS CLOUD In-Memory DB utiliza por defecto la política de expulsión allkeys-lru, por lo que, cuando la memoria se agota, expulsa las claves menos usadas recientemente en lugar de rechazar las escrituras, que es el comportamiento esperado para una caché de lectura con patrón cache-aside. Devolver errores en cada escritura es el comportamiento de una política noeviction, y el clúster no escala automáticamente los nodos para absorber la presión de la caché.
La API de TaskBoard realiza llamadas a IONOS CLOUD AI Model Hub para resumir descripciones de tareas. Durante un pico de tráfico, las solicitudes de inferencia comienzan a devolver respuestas HTTP 429. ¿Qué cambio maneja correctamente esta situación en el código de producción?
AI Model Hub devuelve HTTP 429 Too Many Requests cuando se supera un límite de tasa, por lo que el código de producción debe aplicar un retroceso exponencial y reducir el volumen almacenando en caché los resultados de inferencia, por ejemplo, en In-Memory DB. Los bucles de reintento cerrados empeoran el control de flujo, la API se autentica con un token Bearer y no con autenticación Basic, y el servicio es un endpoint de IONOS CLOUD, no AWS Bedrock.