Verificación de conocimientos - Integración de servicios
Un desarrollador está conectando el Tablero de tareas API a su PostgreSQL de IONOS Cluster. Construyen la cadena de conexión a partir de la salida de Terraform y establecen explícitamente sslmode=disable porque la aplicación se ejecuta dentro del mismo centro de datos virtual. Las conexiones aún negocian TLS independientemente de esta configuración. ¿Qué explica este comportamiento?
IONOS 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 sslmode=disable de la aplicación. Los distractores del controlador y la salida de Terraform son incorrectos porque el comportamiento es una política del lado del servidor de la Cluster administrada, no una biblioteca de cliente o un artefacto de herramientas.
El frontend del navegador TaskBoard necesita permitir a los usuarios cargar adjuntos de archivos grandes directamente a IONOS Object Storage sin que el servidor API haga de proxy para los bytes. ¿Cuál es el enfoque de boto3 que implementa correctamente esto contra IONOS Object Storage?
IONOS Object Storage expone el S3 de AWS API y se autentica con una clave de acceso y una clave secreta, por lo que boto3 debe recibir una clave endpoint_url explícita además de esas credenciales, y las URLs firmadas previamente permiten que el navegador cargue sin que el servidor API toque los bytes. Los tokens Bearer y los roles IAM no autenticán Object Storage, y NFS es un producto de almacenamiento separado y no relacionado.
Un desarrollador agrega un consumidor de Kafka al trabajador de TaskBoard para que pueda reaccionar a eventos de cambio de tarea. La conexión desde el código de la aplicación con solo un nombre de usuario y una contraseña no logra autenticar contra el plano de datos de IONOS Kafka. ¿Qué requiere la configuración correcta del cliente?
El plano de datos de IONOS Kafka autentica a los clientes con autenticación mutua TLS, por lo que el consumidor debe presentar un certificado de cliente sobre una conexión cifrada. El token Bearer solo se aplica al API de administración, el texto sin formato nunca es aceptado y las credenciales de clave de acceso y clave secreta pertenecen a Object Storage, no a Kafka.
TaskBoard utiliza IONOS In-Memory DB (Redis) como caché de sesión y lectura para escalar las lecturas, ya que el PostgreSQL Cluster no tiene réplicas de lectura para descargar ese tráfico. Bajo una carga sostenida, la caché se llena hasta su límite de memoria. Con la configuración predeterminada, ¿qué sucede con las nuevas escrituras una vez que la memoria está llena?
IONOS In-Memory DB tiene como valor predeterminado la política de expulsión allkeys-lru, por lo que cuando la memoria se agota, expulsa las claves que menos se han utilizado recientemente en lugar de rechazar las escrituras, lo que es el comportamiento esperado para una caché de lectura. Devolver errores en cada escritura es el comportamiento de una política noeviction, y el Cluster no escala automáticamente los nodos para absorber la presión de la caché.
La TaskBoard API llama a IONOS AI Model Hub para resumir las descripciones de tareas. Durante un pico de tráfico, las solicitudes de inferencia comienzan a devolver respuestas HTTP 429. ¿Cuál es el cambio que maneja correctamente esto en el código de producción?
AI Model Hub devuelve HTTP 429 Demasiadas solicitudes cuando se excede un límite de velocidad, por lo que el código de producción debe retroceder de manera exponencial y reducir Volume almacenando en caché los resultados de inferencia, por ejemplo en In-Memory DB. Los bucles de reintento ajustados empeoran la limitación, la API se autentica con un token Bearer en lugar de autenticación básica, y el servicio es un punto de conexión de IONOS, no AWS Bedrock.