Las fotos de MercadoFresco ya están en S3, con su ciclo de vida y su versionado. Pero el corazón del negocio sigue en el servidor de la oficina: la base de datos de pedidos. Ahí están los clientes, los productos, las cestas, las rutas de reparto y la facturación. Es el dato que no se puede perder, el que no puede estar caído los viernes a las 19:00, y el que hoy se respalda con un pg_dump a un disco externo que nadie ha probado restaurar nunca.

Esta lección migra esa base de datos a Amazon RDS (Relational Database Service), el servicio gestionado de bases de datos relacionales de AWS. No es solo "PostgreSQL en la nube": es delegar en AWS el parcheo, las copias, la conmutación por error y la replicación, tareas que en MercadoFresco nadie hacía porque nadie tenía tiempo. Y con las copias automáticas y la restauración a un punto en el tiempo cerramos definitivamente el problema 2, la parte que quedó abierta en 02-02 cuando resolvimos las copias de los discos pero no las de los datos transaccionales.

1. Qué es un servicio gestionado y qué deja de ser tu problema
2. RDS frente a PostgreSQL instalado en una EC2
3. Motores disponibles y cuál elige MercadoFresco
4. Crear la instancia RDS por consola
5. Crear la instancia RDS por CLI
6. Multi-AZ: qué es realmente una réplica síncrona en espera
7. Réplicas de lectura: los informes de Sara sin castigar producción
8. Copias automáticas, retención y restauración a un punto en el tiempo
9. Snapshots manuales y el cierre del problema 2
10. Grupos de parámetros y ventanas de mantenimiento
11. Monitorización: métricas básicas y Performance Insights
12. Conectarse desde la aplicación sin credenciales en el código
13. Escalado vertical y almacenamiento autoescalable
14. Migrar desde el servidor de la oficina
15. Costes y cómo parar una instancia de pruebas

En el servidor de la oficina, PostgreSQL era responsabilidad íntegra de Marta: instalarlo, configurarlo, actualizarlo, vigilarlo, respaldarlo y levantarlo cuando se caía. En RDS, AWS asume una parte concreta y bien delimitada de ese trabajo.

Es el modelo de responsabilidad compartida de la lección 01-01 aplicado a un servicio concreto: la línea se mueve hacia arriba, pero nunca desaparece. RDS no va a arreglar una consulta sin índice ni va a diseñar tus tablas.

Lo que RDS no te deja hacer, y conviene saberlo antes de elegirlo:

• No hay acceso al sistema operativo. Nada de SSH a la máquina de la base de datos. Si tu operativa depende de scripts en el servidor, hay que replantearla.
• No hay superusuario real. El usuario maestro tiene el rol rds_superuser, potente pero limitado: no puede hacer todo lo que hace un superuser de PostgreSQL.
• Las extensiones están en lista blanca. Solo puedes instalar las que AWS admite (que son muchas: PostGIS, pg_stat_statements, pgvector…).
• Las versiones tienen calendario de fin de soporte y AWS acabará actualizándote.

La pregunta legítima de Luis es: "podríamos instalar PostgreSQL en una EC2 y sale más barato, ¿no?". La respuesta honesta es que el precio por hora es menor, y el coste total casi nunca.

Elige EC2 solo si necesitas control del sistema operativo, una extensión no admitida, una versión concreta fuera del catálogo, o si tienes un equipo de administradores de bases de datos que ya hace ese trabajo. Para MercadoFresco, que tiene a Marta a media jornada para todo, RDS no es una opción: es la única opción sensata.

El cálculo que zanja la discusión: una db.t3.small en eu-west-1 cuesta alrededor de 30 USD al mes frente a unos 20 USD de la EC2 equivalente. Diez dólares de diferencia. Una sola incidencia nocturna de PostgreSQL al año, con Marta despierta a las 3:00, cuesta más que eso.

MercadoFresco ya usaba PostgreSQL en el servidor de la oficina, así que RDS PostgreSQL permite migrar sin reescribir consultas. Es la decisión de menor riesgo.

Una aclaración que ahorra confusión: Aurora es también RDS, se gestiona desde la misma consola y comparte casi toda la operativa que veremos aquí, pero su arquitectura de almacenamiento es distinta. En 06-03 valoraremos si a MercadoFresco le compensa migrar a Aurora cuando abra en tres ciudades más. Y la elección general entre relacional, clave-valor o almacén de columnas es la lección 06-01.

1. Consola → RDS → verifica la región Irlanda (eu-west-1) → Crear base de datos.
2. Método: Creación estándar (la fácil oculta opciones que necesitas ver).
3. Motor: PostgreSQL, versión 16.x.
4. Plantilla: Producción activa Multi-AZ y el almacenamiento provisionado por defecto. Para aprender, elige Capa gratuita y así no gastas; describimos aquí la de producción.
5. Configuración:
   • Identificador: mercadofresco-pedidos
   • Usuario maestro: mfadmin (no uses postgres ni admin)
   • Contraseña: marca Administrar credenciales maestras en AWS Secrets Manager. Con esto la contraseña nunca la ves, nunca la escribes y AWS la rota sola. Secrets Manager es la lección 04-03.
6. Configuración de la instancia: db.t3.small (2 vCPU, 2 GiB). Para producción real de MercadoFresco, db.m6g.large.
7. Almacenamiento: gp3, 20 GiB, con escalado automático activado y máximo 100 GiB.
8. Disponibilidad: Instancia en espera Multi-AZ. Es la casilla que resuelve la mitad del problema 1 para la base de datos.
9. Conectividad: VPC por defecto, acceso público = No, grupo de seguridad sg-mercadofresco-basedatos. La red se ve en el módulo 3 (03-01 VPC, 03-02 grupos de seguridad).
10. Autenticación: contraseña; opcionalmente autenticación IAM, que elimina las contraseñas.
11. Configuración adicional:
    • Nombre de base de datos inicial: pedidos
    • Copias automáticas: 7 días de retención
    • Ventana de copias: 02:00-03:00 UTC (madrugada en España, tráfico mínimo)
    • Ventana de mantenimiento: domingo 04:00-05:00 UTC
    • Cifrado activado
    • Protección contra eliminación: activada
    • Performance Insights: activado (7 días son gratuitos)
12. Revisa la estimación de coste mensual que muestra la consola y pulsa Crear base de datos.

La creación tarda entre 5 y 15 minutos (más con Multi-AZ, porque construye dos instancias).

Aviso de coste. Una db.t3.micro de una sola AZ entra en la capa gratuita durante 12 meses (750 h/mes, 20 GB de almacenamiento y 20 GB de copias). Multi-AZ duplica el coste de cómputo y no está en la capa gratuita. Si estás practicando, crea la instancia sin Multi-AZ y activa la casilla solo un rato para ver cómo funciona. El apartado final explica cómo pararla y borrarla.

Los parámetros que más importan:

• --manage-master-user-password: AWS genera la contraseña, la guarda en Secrets Manager y la rota automáticamente. Nunca la escribes ni la ves. Es la mejor práctica actual y evita el clásico --master-user-password "Password123" en el historial del shell.
• --no-publicly-accessible: la base de datos no tiene IP pública. Solo se accede desde dentro de la VPC. Innegociable para datos de clientes.
• --max-allocated-storage 100: activa el escalado automático de almacenamiento. Si el disco llega al 90 % de ocupación, RDS lo amplía solo hasta ese techo.
• --deletion-protection: impide borrar la instancia por error. Para borrarla de verdad hay que desactivarlo primero, en un paso consciente y separado.

El punto de enlace tendrá esta forma:

Es un nombre DNS, no una IP, y eso es fundamental. Cuando ocurra una conmutación por error, AWS cambiará a qué apunta ese nombre y la aplicación se reconectará al servidor nuevo sin cambiar ni una línea de configuración. Si en algún sitio del código de MercadoFresco hay una IP de base de datos escrita a mano, hay que quitarla ahora.

Aquí hay un malentendido muy extendido que conviene deshacer con claridad: la instancia en espera de Multi-AZ no sirve tráfico. No es un segundo servidor que reparte carga. No puedes conectarte a ella. Es una copia sincronizada esperando a que la principal falle.

Cómo funciona la replicación síncrona: cuando la aplicación confirma una transacción, PostgreSQL escribe en la principal y espera a que la escritura se haya confirmado también en la instancia en espera antes de responder "hecho" al cliente. Consecuencia doble:

• Ventaja: cero pérdida de datos (RPO = 0). Lo confirmado está en las dos AZ.
• Coste: cada escritura tarda un poco más, porque incluye un viaje de red entre AZ (típicamente 1-2 ms). En cargas con escrituras muy intensas se nota.

1. AWS detecta el fallo (de la instancia, del almacenamiento o de la AZ entera).
2. Cambia el registro DNS del punto de enlace para que apunte a la instancia en espera.
3. La antigua instancia en espera pasa a ser la principal.
4. AWS crea una nueva instancia en espera en la otra AZ, en segundo plano.

Duración típica: 60-120 segundos. Durante ese rato la aplicación recibe errores de conexión. Multi-AZ no es magia invisible: es recuperación rápida, no ausencia de interrupción. La aplicación debe estar preparada:

• Reintentos con espera exponencial en las operaciones de base de datos.
• TTL de DNS bajo en el resolutor del cliente. Un pool de conexiones que cachea la IP para siempre seguirá intentando conectar al servidor caído.
• Pool de conexiones que sepa descartar conexiones muertas (pool_pre_ping en SQLAlchemy).

Se puede provocar una conmutación a propósito para comprobar que la aplicación aguanta. Hazlo en un entorno de pruebas, y hazlo antes de que ocurra sin avisar:

Son cosas distintas y se confunden constantemente:

MercadoFresco necesita las dos, y por razones diferentes: Multi-AZ porque el negocio no puede perder pedidos, y réplicas de lectura porque los informes de Sara están matando la base de datos.

El problema real, medido: Sara ejecuta cada lunes por la mañana una consulta que agrega los pedidos del mes por barrio y por franja horaria. Tarda 4 minutos y durante ese rato la tienda va lenta, porque el mismo servidor está atendiendo a los clientes.

Una réplica de lectura es una copia asíncrona de la base de datos que acepta consultas de solo lectura. Las escrituras siguen yendo a la principal; las lecturas pesadas se dirigen a la réplica.

Fíjate en el etiquetado: Componente=analitica, Propietario=sara, CentroCoste=marketing. La réplica existe para Sara, así que su coste se imputa a marketing y no a operaciones. Esto es exactamente lo que hará posible el informe de asignación de costes de la lección 11-02.

Puntos que hay que tener claros:

• La replicación es asíncrona: la réplica va unos segundos por detrás. Vigila la métrica ReplicaLag. Para informes agregados de ventas es perfectamente aceptable; para "consultar el estado del pedido que acabo de hacer", no.
• La aplicación debe dirigir el tráfico. AWS te da un punto de enlace distinto para la réplica; el código decide cuál usa. RDS no reparte solo.
• Una réplica se puede promover a instancia independiente, lo que rompe la replicación de forma irreversible. Es una estrategia válida de migración entre regiones.
• Se pueden crear en otra región, lo que además da recuperación ante desastres geográfica.

En el código de MercadoFresco, la separación queda así:

La consulta en SQL puro, para verla completa y entender por qué es cara: recorre todos los pedidos del mes, los une con clientes y líneas de pedido, y agrega por dos dimensiones. Con cientos de miles de filas eso es un recorrido secuencial largo que satura la CPU y expulsa datos calientes de la caché de PostgreSQL. Justo lo que no quieres que pase mientras 900 clientes están comprando.

Aquí se cierra el problema 2 de MercadoFresco.

RDS realiza dos cosas de forma continua y automática:

1. Una copia completa diaria durante la ventana que hayas fijado (02:00-03:00 UTC en nuestro caso). Con Multi-AZ, se toma de la instancia en espera, así que producción no lo nota.
2. Copia continua de los registros de transacciones (WAL) a S3, cada 5 minutos.

La combinación de ambas es lo que permite la restauración a un punto en el tiempo (Point-In-Time Recovery, PITR): puedes restaurar la base de datos a cualquier segundo dentro del periodo de retención, no solo a la hora de la copia diaria.

El escenario que justifica todo esto: el martes a las 11:47, un despliegue de Luis ejecuta por error un UPDATE sin WHERE que pone a cero el precio de todos los productos. A las 11:52 alguien se da cuenta.

Que la restauración cree una instancia nueva es deliberado y muy útil: puedes verificar los datos antes de tocar producción, o incluso extraer solo la tabla afectada y copiarla, en lugar de volver atrás toda la base de datos y perder los pedidos legítimos de esos cinco minutos.

Sobre la retención:

Las copias automáticas se almacenan gratis hasta el tamaño de la base de datos; más allá se cobran a precio de snapshot. Y hay un detalle crítico: al eliminar la instancia, las copias automáticas se borran con ella. Solo los snapshots manuales sobreviven.

Un snapshot manual es una copia que tú creas y que vive hasta que tú la borres, incluso si eliminas la instancia. Es la copia para hitos: antes de una migración de esquema, antes de una actualización de versión mayor, al cierre del ejercicio fiscal.

Comparación de las tres formas de recuperación en RDS:

Y así queda cerrado el problema 2 de MercadoFresco, sumando lo de 02-02 y lo de esta lección:

Con una advertencia que se repite y no sobra: la prueba de restauración trimestral es parte del plan, no un extra. Marta la tiene en el calendario.

Como no hay acceso al sistema operativo, no puedes editar postgresql.conf. En su lugar, RDS usa grupos de parámetros: un conjunto con nombre de ajustes que se asocia a una o varias instancias.

El grupo por defecto no se puede modificar, así que lo primero es crear uno propio:

Qué hemos configurado y por qué:

• log_min_duration_statement = 1000: registra toda consulta que tarde más de 1 segundo. Es la forma más directa de encontrar las consultas que hunden la tienda los viernes.
• shared_preload_libraries = pg_stat_statements: activa la extensión que acumula estadísticas por consulta. Base de cualquier trabajo serio de optimización.
• ApplyMethod: immediate se aplica al momento; pending-reboot requiere reiniciar la instancia. Un parámetro dinámico marcado como pendiente no está haciendo nada todavía, y esto despista mucho.

Sobre la ventana de mantenimiento: es el intervalo semanal en el que AWS aplica parches del sistema operativo y del motor. Elígela en el valle de tráfico (domingo de madrugada para MercadoFresco, nunca un viernes por la tarde). Con Multi-AZ, el mantenimiento se aplica primero a la instancia en espera, luego se conmuta y después se parchea la otra: la interrupción se reduce al tiempo de la conmutación.

Las actualizaciones de versión menor pueden ser automáticas (--auto-minor-version-upgrade); las de versión mayor (de PostgreSQL 16 a 17) nunca lo son: requieren tu acción explícita y hay que probarlas antes en una instancia restaurada desde un snapshot.

RDS publica métricas en CloudWatch sin configurar nada. Las que hay que mirar:

Performance Insights va un paso más allá: es un panel que muestra la carga de la base de datos descompuesta por consulta, por usuario, por host y por tipo de espera. Esa última dimensión es la que resuelve incidencias: no te dice solo "la CPU está al 90 %", te dice "el 70 % de la carga está esperando bloqueos de la tabla pedidos, y la consulta responsable es esta".

Los 7 días de retención son gratuitos y merece la pena activarlo siempre. La monitorización a fondo, con alarmas, paneles y agregación de registros, es la lección 05-01.

Primero, la comprobación manual desde una instancia EC2 de la tienda (recuerda: la base de datos no es pública, así que hay que conectarse desde dentro de la VPC):

Una vez dentro, comprobaciones útiles:

Y así se conecta la aplicación, leyendo el secreto en el arranque y sin que ninguna credencial toque el código ni el repositorio:

Las tres reglas que resume este código:

1. Ninguna credencial en el código ni en el repositorio. Solo el identificador del secreto.
2. Autorización por rol IAM, no por claves de acceso. La instancia EC2 tiene un rol que le permite leer ese secreto concreto y nada más.
3. sslmode=require: la conexión va cifrada. RDS proporciona el certificado.

Escalado vertical (cambiar la clase de instancia). Es una operación con interrupción, salvo con Multi-AZ, donde AWS modifica primero la instancia en espera, conmuta y luego la otra: la parada se reduce a los 60-120 segundos de la conmutación.

--apply-immediately aplica el cambio ya, con la interrupción correspondiente. Sin ese parámetro, el cambio espera a la ventana de mantenimiento, que es lo que quieres en producción salvo urgencia.

Escalado del almacenamiento. Se puede ampliar en cualquier momento y sin parar, pero no reducir. Con --max-allocated-storage, RDS lo hace solo:

Cuándo escalar cada cosa, en el caso de MercadoFresco:

El orden importa: subir de tamaño es la última opción, no la primera. Un índice que falta cuesta cero euros al mes; una clase de instancia mayor cuesta todos los meses, para siempre.

Con la base de datos de MercadoFresco (unos pocos GB y una ventana de mantenimiento nocturna aceptable), la migración clásica con volcado y restauración es suficiente.

Por qué --no-owner --no-privileges: los roles y permisos del servidor de origen no existen en RDS, y sin esas opciones la restauración se llena de errores por intentar asignar objetos a usuarios inexistentes.

Verificación obligatoria antes de conmutar el tráfico:

Plan de conmutación de MercadoFresco, un domingo de madrugada:

1. 02:00 — Poner la tienda en modo mantenimiento (solo lectura).
2. 02:05 — pg_dump final del servidor de la oficina.
3. 02:20 — pg_restore en RDS y ANALYZE.
4. 02:40 — Verificar recuentos y ejecutar la batería de pruebas de humo.
5. 02:50 — Cambiar las variables de entorno de la aplicación al nuevo punto de enlace.
6. 03:00 — Quitar el modo mantenimiento y vigilar métricas durante una hora.
7. El servidor de la oficina se deja encendido y sincronizado una semana, por si hay que volver atrás.

Cuando no se puede parar la tienda, la herramienta es AWS DMS (Database Migration Service): copia el estado inicial y después replica los cambios en continuo (change data capture), de modo que la ventana de corte se reduce a segundos. Además puede migrar entre motores distintos (de Oracle a PostgreSQL, por ejemplo). Para MercadoFresco es exagerado; para una migración sin parada, es el camino.

Componentes de la factura de RDS:

Coste mensual de la configuración de producción de MercadoFresco:

Unos 78 € al mes por una base de datos con alta disponibilidad, copias automáticas, PITR de 7 días y una réplica para analítica. Comparado con los 6.000 € del servidor original —que no tenía nada de eso— y con el tiempo que Marta dedicaba a mantenerlo, la conversación económica se vuelve fácil.

Parar una instancia de pruebas:

Dos limitaciones importantes: RDS solo permite tener una instancia parada 7 días; al octavo la arranca sola. Y una instancia Multi-AZ no se puede parar. Para entornos de desarrollo que solo se usan en horario laboral, lo práctico es programar el arranque y la parada, o simplemente borrar y recrear desde un snapshot.

Eliminar por completo cuando termines la práctica:

• Creer que la instancia en espera de Multi-AZ sirve lecturas. No. Para eso están las réplicas de lectura. Es el malentendido número uno de RDS.
• Poner --publicly-accessible para "poder conectarme desde casa". Expone la base de datos a internet. La forma correcta es un bastión, Session Manager o una VPN.
• Escribir la contraseña en el comando o en el código. Usa --manage-master-user-password y Secrets Manager (04-03).
• Retención de copias a 0 días. Desactiva el PITR. Es la configuración que convierte un error humano recuperable en una pérdida definitiva.
• Olvidar que las copias automáticas se borran con la instancia. Antes de eliminar, saca un snapshot final.
• Cambiar un parámetro pending-reboot y esperar que actúe. No hace nada hasta reiniciar.
• Restaurar y no ejecutar ANALYZE. Sin estadísticas, el planificador toma decisiones pésimas y parece que RDS "va lento".
• Poner la ventana de mantenimiento en hora punta. Domingo de madrugada, nunca viernes por la tarde.
• Subir de clase de instancia antes de mirar las consultas. Un índice que falta cuesta 0 USD al mes; una instancia mayor, todos los meses.
• Leer de la réplica lo que el usuario acaba de escribir. El retardo asíncrono hará que a veces no aparezca. Lecturas críticas, siempre a la principal.
• No probar nunca una conmutación por error. Provócala en un entorno de pruebas y comprueba que la aplicación se reconecta. Descubrirlo en producción sale caro.
• Consejo: activa Performance Insights desde el primer día. Es gratis 7 días y el día que haya una incidencia querrás tener el histórico.

MercadoFresco abre en tres ciudades más (problema 3). La previsión es:

• El pico de los viernes pasa a 2.100 pedidos/hora (escrituras intensas).
• Sara pasa de un informe semanal a un panel que se refresca cada 15 minutos.
• Aparece un requisito nuevo: si se pierde la región eu-west-1 entera, el negocio debe poder operar en menos de 4 horas.
• Se mantiene el requisito de no perder ningún pedido confirmado.

Diseña la topología de RDS: qué instancias, de qué tipo, en qué AZ y regiones, y qué mecanismo cubre cada requisito. Indica qué requisito no puede cubrir RDS por sí solo.

El jueves a las 16:12, un script de sincronización de catálogo ejecuta por error:

Ha borrado 47.000 líneas de pedidos históricos que sí eran válidas. Nadie se da cuenta hasta el viernes a las 10:30, cuando Sara ve que las cifras de julio no cuadran. En ese tiempo se han registrado unos 1.400 pedidos nuevos que no se pueden perder.

Describe el procedimiento completo de recuperación, con los comandos, y explica por qué no se puede simplemente restaurar la base de datos al jueves a las 16:11.

Para cada consulta de MercadoFresco, indica si debe ir a la instancia principal o a la réplica de lectura, y justifica en una frase:

• A) INSERT de un pedido nuevo desde la cesta.
• B) "Mis pedidos" de un cliente que acaba de comprar hace 3 segundos.
• C) Informe mensual de ventas agregadas por barrio.
• D) Listado del catálogo de productos en la página principal.
• E) Comprobación de stock justo antes de confirmar un pedido.
• F) Exportación nocturna de todos los pedidos a S3 para analítica.

Solución 1.

Topología resultante:

Lo que RDS no cubre por sí solo: el pico de escrituras de los viernes sigue dependiendo de una sola instancia escritora. Escalar verticalmente tiene un techo. Las soluciones reales están fuera de esta lección: encolar los pedidos con SQS para absorber el pico y escribirlos a ritmo sostenido (módulo 7), cachear las lecturas calientes con ElastiCache (06-05), o repartir la escritura con un modelo distinto de datos (DynamoDB, 06-02). Reconocer ese techo es parte de saber usar RDS.

Solución 2.

Por qué no se puede restaurar sin más al jueves a las 16:11: eso devolvería la base de datos al estado de ese instante, y con ello desaparecerían los 1.400 pedidos registrados entre el jueves por la tarde y el viernes por la mañana. Se arreglaría un problema creando otro peor. La restauración completa solo vale cuando el daño se detecta en minutos.

El procedimiento correcto es restaurar en paralelo y recuperar solo lo borrado:

Lecciones que deja el incidente: el DELETE debía haberse ejecutado dentro de una transacción con verificación previa del recuento; los scripts de mantenimiento no deben usar el usuario maestro sino un rol con permisos acotados (04-01); y una alarma sobre variaciones bruscas del número de filas habría avisado el jueves y no el viernes.

Solución 3.

Patrón general: escrituras y lecturas críticas o inmediatas → principal; lecturas analíticas, históricas o tolerantes al retardo → réplica.

La base de datos de pedidos de MercadoFresco ya está en AWS, y con ella el corazón del negocio. Entiendes qué significa un servicio gestionado: AWS asume el hardware, el sistema operativo, los parches del motor, las copias y la conmutación por error; tú sigues siendo responsable del esquema, los índices, las consultas y la seguridad de la aplicación. Sabes también qué renuncias a cambio —acceso al sistema operativo, superusuario real, extensiones fuera de lista— y en qué casos concretos eso obliga a elegir PostgreSQL sobre EC2 en lugar de RDS.

Has creado la instancia mercadofresco-pedidos por consola y por CLI, con las decisiones que importan tomadas conscientemente: contraseña gestionada en Secrets Manager para no escribirla nunca, sin acceso público, cifrado activado, protección contra eliminación, escalado automático de almacenamiento, retención de copias de 7 días y ventanas de copia y mantenimiento colocadas en el valle de tráfico y nunca un viernes por la tarde.

Has deshecho el malentendido más común de RDS: la instancia en espera de Multi-AZ no sirve tráfico. Es una réplica síncrona que garantiza cero pérdida de datos y conmuta en 60-120 segundos cambiando el DNS del punto de enlace, con la contrapartida de sumar latencia a cada escritura y de exigir que la aplicación reintente. Frente a ella, las réplicas de lectura son asíncronas, sí se pueden consultar y son la herramienta correcta para que el panel de Sara no castigue a producción; has visto en código y en tabla qué consulta va a cada sitio.

Y has cerrado el problema 2 de MercadoFresco. Entre los snapshots de EBS automatizados con DLM de la lección 02-02, el versionado de S3 de la 02-03 y ahora las copias automáticas de RDS con registros de transacciones cada cinco minutos, la empresa ha pasado de "un pg_dump a un disco externo cuando alguien se acuerda" a poder restaurar a cualquier segundo de los últimos siete días. Has practicado la recuperación real de un borrado masivo restaurando en paralelo y reinsertando solo lo perdido, sin sacrificar los pedidos posteriores. Sumas a eso los snapshots manuales que sobreviven al borrado de la instancia, los grupos de parámetros con log_min_duration_statement y pg_stat_statements para cazar consultas lentas, Performance Insights para saber en qué espera realmente la base de datos, la conexión desde la aplicación sin una sola credencial en el código, el escalado vertical y de almacenamiento con su regla de oro —mira los índices antes de subir de clase— y el plan completo de migración con pg_dump/pg_restore y su alternativa sin parada, AWS DMS.

Queda una última pieza del módulo. Tenemos servidores que hay que dimensionar, arrancar y pagar aunque estén ociosos. Pero hay tareas de MercadoFresco que no necesitan un servidor esperando: generar la miniatura de una foto cuando se sube, responder a una consulta puntual del estado de un pedido, procesar un fichero. En la lección 02-05, «AWS Lambda», escribiremos código que se ejecuta solo cuando ocurre algo y solo se paga mientras corre, conectaremos por fin el evento de S3 que dejamos configurado en 02-03 para generar las miniaturas del catálogo, y recapitularemos qué piezas de MercadoFresco están ya en la nube y qué falta por construir.