Respuesta.

En una arquitectura de microservicios, cada servicio a menudo es responsable de su propia base de datos. Para gestionar las migraciones de esquemas de datos, se deben aplicar herramientas de migración especializadas (Liquibase, Flyway, Alembic), y ejecutarlas a través de un pipeline de CI/CD para automatización y previsibilidad de resultados.

Una buena práctica es que cada migración se prepare como un script de migración con versionado e idempotencia: la ejecución repetida de un mismo cambio no debe causar error ni desincronización.

Ejemplo de migración en Python con Alembic:

from alembic import op
import sqlalchemy as sa

def upgrade():
    op.add_column('user', sa.Column('status', sa.String(8)))

def downgrade():
    op.drop_column('user', 'status')

Características clave:

• Automatización de migraciones a nivel de CI/CD
• Idempotencia — posibilidad de reaplicación sin dañar la estructura
• Versionado de esquemas de datos y retroceso

Preguntas engañosas.

¿Es posible modificar el esquema de la base de datos manualmente en producción sin migraciones (DDL manual)?

Esto se recomienda encarecidamente: se perderá el control sobre el estado del esquema y surgirán dificultades con el retroceso/seguimiento de cambios.

¿Es cierto que en una arquitectura de microservicios las migraciones deben realizarse de manera centralizada para todos los servicios?

No, cada equipo/servicio es responsable de su propio esquema y su propio pipeline de migraciones. La centralización contradice los principios de independencia de los servicios.

¿Es completamente seguro el rollback de migraciones?

No: no siempre es posible retroceder cambios, especialmente si la estructura o el formato de datos ha cambiado (por ejemplo, si se ha eliminado un campo y se han perdido datos). Es mejor diseñar migraciones teniendo en cuenta el retroceso.