La API de una empresa recibe datos en tiempo real de dispositivos de monitoreo y los almacena en una instancia de base de datos de Amazon RDS. El volumen de datos entrantes fluctúa y, durante el tráfico intenso, la API agota el tiempo de espera porque la base de datos no puede procesar el volumen de escritura. Un arquitecto de soluciones debe minimizar las conexiones a la base de datos y garantizar que no haya pérdida de datos durante el tráfico intenso. ¿Qué solución cumple con estos requisitos?

La opción correcta es modificar la API para que escriba en una cola de Amazon SQS y usar una función de AWS Lambda para procesar esos datos en la base de datos. Esto desacopla la API de la base de datos, permitiendo que la API responda rápidamente y colocando los datos en SQS para su procesamiento asíncrono. SQS actúa como un búfer, absorbiendo picos de tráfico y evitando la pérdida de datos, mientras que Lambda puede escalar para procesar los mensajes de la cola a una velocidad que la base de datos pueda manejar, minimizando las conexiones directas a la base de datos. Aumentar el tamaño de la instancia de la base de datos podría ayudar con el rendimiento, pero no resuelve el problema fundamental del desacoplamiento y no garantiza la no pérdida de datos durante picos extremos. Modificar la base de datos a Multi-AZ mejora la disponibilidad y la tolerancia a fallos, pero no distribuye las escrituras de manera efectiva para manejar un alto volumen de tráfico de escritura en una sola instancia. Escribir en Amazon SNS no es adecuado para este caso de uso, ya que SNS es un servicio de publicación/suscripción para notificaciones, no una cola de mensajes persistente para procesar datos de forma asíncrona.