Un límite de servicio desde patrones de acceso a datos

Un límite de servicio resulta creíble cuando cada lado puede confirmar sus propios cambios sin pedir que el otro participe en la misma transacción. Los organigramas, los mapas de capacidades y los sustantivos de un taller pueden sugerir dónde buscar. La base de datos indica si la separación propuesta sobrevivirá al contacto con producción.

Empiezo por los patrones de acceso a datos porque los sistemas antiguos registran sus contratos reales en lecturas, escrituras, bloqueos, disparadores, procesos y procedimientos de recuperación. La parte difícil es separar el acoplamiento accidental de una invariante del negocio. Una pantalla que lee nombres de clientes junto a las facturas crea una dependencia de presentación. Una rutina de contabilización que actualiza una factura, un asiento y un saldo de crédito en un solo commit puede codificar una invariante que no tolera el éxito parcial. Esas dos dependencias exigen tratamientos distintos.

El resultado útil no es un bonito diagrama de dominios. Es un conjunto de pruebas: un mapa de propiedad de tablas, una matriz de tablas escritas en la misma transacción, un mapa de lecturas que cruzan dominios candidatos y una lista breve de invariantes que explican los grupos más fuertes. Con esas pruebas, un equipo puede elegir un límite y declarar con precisión qué debe cambiar antes del primer despliegue independiente.

Empiece por las transacciones, no por los nombres de tabla

Las tablas escritas en la misma transacción son la primera señal más fuerte porque la aplicación trata actualmente esos cambios como una unidad de éxito o fracaso. Si invoice, ledger_entry y customer_balance cambian repetidamente bajo un mismo identificador de transacción, separarlas entre servicios sustituiría un commit local por coordinación, compensación o una regla de negocio modificada.

Los nombres engañan. Una tabla llamada customer puede guardar la identidad de la cuenta, el estado de crédito, preferencias de envío y un total de ventas desnormalizado. Una tabla llamada order_status puede funcionar como cola compartida por logística y facturación. Los prefijos suelen reflejar al equipo que creó una tabla, no el comportamiento que ahora depende de ella. Incluso las claves foráneas solo describen relaciones referenciales declaradas. No dicen nada sobre un programa nocturno que lee tres tablas, escribe dos más y debe poder reiniciarse después de la fila 80.000.

Defina una transacción como la ve la base de datos: las sentencias entre begin y commit o rollback, incluidas las sentencias emitidas por disparadores y procedimientos almacenados. Cada sentencia con autocommit forma su propia transacción. Los procesos por lotes necesitan una identidad adicional para la ejecución y el punto de control porque un bucle que confirma cada 500 registros abarca una operación de negocio mayor que cada transacción individual de base de datos.

Capture al menos estos campos para cada acceso observado:

• identificador de transacción y marca de tiempo
• ejecutable, proceso, ruta o punto de entrada
• tabla y tipo de operación
• filas afectadas o una banda aproximada de cardinalidad
• cadena de llamadas o nombre del procedimiento almacenado cuando esté disponible

No empiece asignando cada tabla a un dominio. Reúna primero los hechos sin forzarlos a dar la respuesta deseada. Las etiquetas de dominio llegan después de que aparezcan los grupos de escritura conjunta. Este orden evita que el vocabulario del taller contamine la medición.

Construya una matriz de coescritura que exponga el trabajo atómico

Una matriz de coescritura cuenta cuántas veces reciben escrituras dos tablas dentro de la misma transacción de base de datos. Convierte miles de trazas en un grafo ponderado: las tablas son nodos, y una arista conecta dos tablas cuando al menos una transacción escribe ambas. El peso de la arista puede registrar el número de transacciones, las filas afectadas o la proporción de escrituras de cada tabla que participa en el par.

Supongamos que las trazas normalizadas terminan en una tabla llamada data_access:

create table data_access (
  captured_at timestamp not null,
  transaction_id varchar(100) not null,
  entry_point varchar(200) not null,
  table_name varchar(200) not null,
  operation varchar(10) not null,
  rows_affected bigint
);

with writes as (
  select distinct transaction_id, table_name
  from data_access
  where operation in ('INSERT', 'UPDATE', 'DELETE')
), pairs as (
  select a.table_name as table_a,
         b.table_name as table_b,
         count(*) as shared_transactions
  from writes a
  join writes b
    on a.transaction_id = b.transaction_id
   and a.table_name < b.table_name
  group by a.table_name, b.table_name
)
select table_a, table_b, shared_transactions
from pairs
order by shared_transactions desc;

La salida tiene la forma table_a | table_b | shared_transactions. Los valores mayores merecen revisión, pero los recuentos brutos no bastan. Un proceso de mantenimiento puede dominar el volumen sin codificar ninguna invariante visible para el usuario. Una contabilización poco frecuente de cierre anual puede contener el requisito atómico más fuerte del sistema. Añada el punto de entrada a la agrupación y compare el mismo par entre solicitudes en línea, procesos programados, importaciones y herramientas de operadores.

Normalice el peso en las dos direcciones. Si el 98 por ciento de las escrituras en customer_balance ocurre junto con ledger_entry, esa arista importa aunque esas transacciones sean una parte pequeña de toda la actividad del libro mayor. Utilizo dos medidas condicionales: transacciones que escriben A y también B, divididas por todas las transacciones que escriben A; y el cálculo inverso. Un resultado asimétrico suele revelar una tabla satélite que pertenece a un agregado mayor.

El muestreo debe preservar los límites de las transacciones. Capturar una de cada cien sentencias SQL destruye las pruebas porque la muestra puede retener una mitad de una coescritura y descartar la otra. Muestree transacciones completas mediante el identificador o capture todas las transacciones de puntos de entrada elegidos. Enmascare valores si hace falta, pero conserve nombres de tabla, tipos de operación, tiempos y pertenencia a cada transacción.

Separe las invariantes del negocio de los hábitos de implementación

Un grupo denso de coescrituras propone un límite, pero no lo demuestra. El equipo debe explicar por qué existe cada arista fuerte y qué se rompería si las dos escrituras se confirmaran por separado. Esa explicación distingue una invariante del negocio de un código que usa una conexión compartida por casualidad.

Pida la frase del fallo. Para una factura y su asiento, podría ser: «Finanzas nunca debe reconocer una factura sin los asientos de debe y haber correspondientes». Para un pedido y un registro de auditoría: «Los operadores necesitan constancia de quién modificó el pedido». La primera quizá requiera estado atómico o un modelo de contabilización rediseñado con cuidado. La segunda suele poder pasar a un evento duradero o a un outbox de base de datos sin que la tabla de auditoría forme parte de la propiedad del pedido.

Clasifique cada arista de coescritura en uno de cuatro motivos:

1. Una invariante del negocio exige que todos los cambios tengan éxito juntos.
2. Una limpieza referencial o una cascada mantiene coherentes los datos guardados.
3. Un valor derivado o un índice se mantiene de forma síncrona para acelerar lecturas.
4. El código reutilizó una transacción porque las tablas estaban cerca.

Solo el primer motivo ofrece pruebas sólidas de que las tablas pertenecen al mismo límite de consistencia. El segundo puede desaparecer cuando un servicio posee el borrado y publica el hecho. El tercero suele ser un problema de proyección. El cuarto es deuda de migración.

Los disparadores merecen especial atención porque las trazas de la aplicación pueden ocultarlos. Una rutina puede parecer que actualiza shipment, mientras un disparador ajusta inventory, inserta stock_movement y escribe en una cola de integración. Lea las definiciones de disparadores y el cuerpo de los procedimientos almacenados, y atribuya sus escrituras a la transacción y al punto de entrada que las inició. De otro modo, el límite propuesto fallará en el primer caso de producción que active el comportamiento oculto de la base.

Los bloqueos y el tratamiento de errores aportan más pruebas. Un código que reintenta un interbloqueo entre dos tablas, convierte una infracción de restricción en un mensaje de negocio o revierte ambos cambios después de una validación fallida probablemente depende de su destino compartido. Documente la restricción o la regla de recuperación exacta. «Estas tablas están acopladas» es demasiado impreciso para guiar una migración.

Trate las lecturas entre dominios como otra clase de deuda

Una lectura entre dominios candidatos no invalida automáticamente el límite. Las lecturas pueden usar API, proyecciones replicadas, cachés, instantáneas o almacenes analíticos sin coordinar commits. La pregunta de diseño es qué frescura y exhaustividad deben tener los datos cuando el lector toma una decisión.

Construya una matriz de lecturas después de que aparezcan los posibles propietarios de las escrituras. Las filas representan puntos de entrada y las columnas, dominios propuestos. Cada celda registra tablas leídas, frecuencia, cardinalidad y si el mismo punto de entrada escribe en algún lugar. Preste máxima atención a las lecturas de decisión, cuyo resultado determina una escritura posterior. Un informe que une facturación y clientes puede tolerar una proyección retrasada. Una comprobación de crédito antes de aprobar un pedido puede necesitar datos actuales o un protocolo de reserva.

El patrón peligroso consiste en leer del dominio B, calcular en el código de la aplicación y escribir después en A suponiendo que B no cambió. Un monolito local puede ocultar esa carrera dentro de una transacción de base de datos bloqueando las filas de B. Tras separar los servicios, una llamada API síncrona devuelve un valor, pero no extiende la transacción del llamador por la red. El valor puede cambiar antes de que A confirme.

Registre una clase de frescura para cada lectura transversal:

• exacta en el momento de decidir
• retraso limitado con un máximo declarado
• último valor conocido con conciliación
• instantánea histórica
• solo visualización

Esta clasificación convierte una dependencia vaga como «los pedidos necesitan datos del cliente» en un contrato. Los nombres de cliente que solo se muestran pueden vivir en una proyección de pedidos. Una comprobación del límite de crédito puede exigir que el dominio de clientes posea una reserva, de modo que el servicio de pedidos le pida reservar capacidad en vez de obtener una cifra y decidir por su cuenta.

Las uniones amplias para informes no deben dictar los límites de las transacciones. Llévelas a una proyección de informes alimentada por cambios de sus propietarios, o conserve una réplica de lectura durante la transición. Obligar a los servicios operativos a llamarse fila por fila para mantener un informe antiguo crea una unión de red lenta y propaga fallos de disponibilidad. Los informes necesitan un producto de datos explícito, no acceso accidental a todos los esquemas operativos.

Las vistas y consultas almacenadas pueden ocultar el cruce. Expanda cada vista hasta sus tablas base al construir la matriz, pero conserve el nombre como contrato del consumidor. Una docena de programas puede leer open_account_summary sin saber que une cuentas por cobrar, estado del cliente y disputas. Sustituir la vista una vez puede ser más sencillo que modificar cada programa, pero su regla de actualización sigue necesitando propietario. Mida si los llamadores filtran, agregan o recuperan todo el conjunto para decidir si conviene una proyección, un punto de consulta o una exportación masiva.

Observe también las lecturas negativas. El código suele preguntar si una fila no existe: ninguna factura impagada, ningún bloqueo activo, ninguna solicitud anterior con esta referencia. El retraso de replicación hace especialmente peligrosa la ausencia, porque una proyección desactualizada parece exactamente un permiso para continuar. Coloque estas comprobaciones junto a otras lecturas de decisión y nombre a la autoridad que puede responderlas. Si la comprobación protege la unicidad o un límite de gasto, traslade la decisión a esa autoridad en vez de copiar la tabla y confiar en ganar la carrera de replicación.

El comportamiento ante errores de lectura también forma parte del contrato. Cuando el propietario remoto no está disponible, el llamador debe rechazar, usar un valor antiguo dentro de un límite, poner el trabajo en cola o continuar con un riesgo explícito. La elección correcta depende de la regla de negocio. Una política genérica de reintentos oculta la decisión hasta una caída, cuando los operadores tienen menos margen para razonar.

Un límite falla cuando lo cruza la invariante

La prueba práctica de una separación propuesta es sencilla: ¿puede cada lado aceptar o rechazar sus propios comandos con los datos que posee y conservar las reglas de negocio declaradas? Si un comando del lado A necesita que el lado B participe en el mismo commit, el límite no está listo.

Piense en una rutina de pedidos que ejecuta estas acciones en una transacción:

1. Leer el crédito disponible del cliente con un bloqueo de fila.
2. Insertar el pedido y sus líneas.
3. Aumentar la exposición comprometida del cliente.
4. Insertar un registro de auditoría y confirmar.

Un organigrama puede situar la gestión de clientes y la de pedidos en departamentos distintos. Una extracción directa convertiría los pasos dos y tres en una transacción distribuida. Llamar primero al servicio de clientes no resuelve el problema: la inserción del pedido puede fallar después de aumentar la exposición. Llamarlo al final produce el huérfano inverso. Reintentar a ciegas arriesga un recuento doble.

Hay tres opciones honestas. Mantener la exposición de crédito y la aceptación del pedido dentro de un mismo límite. Trasladar la decisión a una reserva de crédito propiedad del lado de clientes, con un identificador de reserva idempotente y operaciones explícitas de confirmación o liberación. O cambiar la regla de negocio para permitir una discrepancia temporal, conciliar después y retener los pedidos afectados. Cada opción cambia la propiedad o la semántica. Un intermediario de mensajes por sí solo no cambia ninguna.

La reserva necesita estados y comportamiento temporal, no un nombre de evento optimista. reserve debe devolver el mismo resultado para el mismo identificador. confirm debe tolerar repeticiones. La caducidad debe contemplar una confirmación tardía. Los operadores deben poder ver las reservas que nunca llegan a un estado terminal. Si la organización no puede expresar esas reglas, no ha eliminado la transacción distribuida; ha cambiado el nombre de la incertidumbre.

Por eso rechazo «separar por capacidad de negocio» como método completo. El consejo es popular porque las capacidades producen diagramas que directivos e ingenieros pueden discutir juntos. Es útil para generar candidatos. Es incorrecto como prueba final porque un mapa de capacidades no revela el alcance de los commits, los disparadores, las lecturas de decisión bloqueadas ni la semántica de reinicio.

Los procesos por lotes revelan lo que omiten las trazas en línea

El tráfico en línea rara vez cubre el contrato completo de un sistema antiguo. El cierre de mes, la liquidación, las importaciones, los reprocesamientos y las correcciones de operadores suelen cruzar tablas que las solicitudes normales nunca tocan. Un límite elegido solo con trazas HTTP puede parecer limpio hasta la primera ejecución programada.

Inventaríe cada ejecutable que se conecta a la base de datos, incluidos scripts lanzados por programadores de tareas, procesos almacenados, clientes de escritorio, macros de hojas de cálculo y utilidades de soporte. Vincule las sesiones de base de datos con nombres de ejecutables o credenciales cuando sea posible. Las credenciales compartidas lo dificultan, así que combine metadatos de sesión, definiciones del programador, búsquedas en el código y registros de auditoría de la base.

La cadencia de commit en los lotes importa. Un programa que lee todas las facturas sin contabilizar, crea asientos, marca las filas de origen y confirma cada 500 elementos tiene al menos tres ámbitos:

• la transacción de base de datos de cada bloque
• el punto de control usado para reanudar la ejecución
• el requisito de negocio de todo el periodo de contabilización

Separar servicios puede conservar los commits por bloque y romper el reinicio. Imagine que el nuevo servicio de libro mayor acepta 430 asientos antes de que falle el llamador. El programa antiguo reinicia desde su último punto de control y vuelve a enviarlos. Sin un identificador de origen estable y aceptación idempotente, el destino contabiliza duplicados. Con idempotencia pero sin conciliación, el origen todavía puede mostrar 70 elementos pendientes aunque el libro mayor ya los aceptó.

Recorra un camino real de reinicio para cada lote importante. Registre dónde fija el punto de control, qué escrituras ocurren antes, cómo reconoce trabajo previo, qué revisan los operadores y cómo repara una ejecución parcial. Asigne después la propiedad de esa recuperación. Los diagramas de servicios tienden a omitir procedimientos operativos, aunque esos procedimientos suelen guardar la única definición de consistencia que funciona.

Los procesos infrecuentes deben ponderarse por sus consecuencias además de por su frecuencia. Marco una arista como importante para operaciones cuando un fallo bloquea el cierre, las nóminas, los envíos, los informes regulatorios u otro acontecimiento de negocio concreto. Es una valoración, no una puntuación matemática falsa. El objetivo es impedir que las actualizaciones de inicio de sesión con mucho volumen oculten una invariante contable de poco volumen.

Elija la propiedad de las tablas antes que las API

Cada tabla mutable necesita un propietario propuesto antes de diseñar las API. El acceso compartido de escritura permite que ambos servicios conserven los atajos antiguos, por lo que el límite solo existe en los diagramas de despliegue. La propiedad significa que un servicio decide las transiciones de estado válidas, realiza las escrituras y atiende las reparaciones.

Cree un registro de tablas con estas columnas: tabla, propietario propuesto, puntos de entrada que escriben, grupo de coescritura, lecturas de decisión transversales, disparadores, procesos por lotes e invariante sin resolver. Asigne también las tablas derivadas. «Compartido» es un estado temporal de migración con una condición de salida, no un dominio.

Busque después todas las rutas de escritura en el árbol de código. La búsqueda estática encuentra sentencias y mapeos ORM que las trazas no captaron. Las trazas dinámicas encuentran SQL generado y llamadas a procedimientos poco evidentes que la búsqueda pasó por alto. Ninguna fuente basta sola. Compárelas y explique las discrepancias, sobre todo las utilidades inactivas que todavía tienen credenciales de producción.

Los comandos de API deben expresar decisiones propiedad del receptor. reserveCredit(orderId, amount) es más sólido que getAvailableCredit(customerId) seguido de un cálculo en el llamador. postInvoice(invoiceId, lines) es más sólido que exponer operaciones CRUD para las tablas del libro mayor. El comando permite que el propietario proteja su invariante aunque cambie su almacenamiento.

Las lecturas también necesitan propiedad, incluso cuando los datos están copiados. Una proyección puede contener el nombre y estado del cliente dentro del servicio de pedidos, pero el servicio de clientes sigue siendo la autoridad. Guarde el identificador y la versión del origen o la posición del evento para que la conciliación detecte actualizaciones perdidas o reordenadas. Decida qué hace el lector cuando la proyección está atrasada: continuar, advertir, rechazar o consultar de forma síncrona. No deje esta decisión al ingeniero que atienda el primer incidente.

Los permisos de base de datos pueden imponer el límite antes de la extracción física. Conceda derechos de escritura al futuro propietario y convierta a los demás escritores en llamadores por etapas controladas. Audite los intentos denegados durante las pruebas. Una división de esquemas sin cambios de permisos es cosmética porque cualquier proceso antiguo puede seguir cruzándola.

Puntúe los límites candidatos por el trabajo que requieren

Una puntuación útil estima el coste de migración y el riesgo operativo; no pretende descubrir la arquitectura mediante aritmética. Comparo los candidatos con el mismo conjunto de preguntas observables y conservo las pruebas sin procesar junto a cada calificación.

Para cada límite propuesto, registre:

• número e importancia para el negocio de las transacciones que escriben ambos lados
• lecturas de decisión que exigen estado remoto actual
• flujos por lotes y de recuperación que cruzan la línea
• tablas con varios escritores activos
• informes y exportaciones que necesitan una ruta de lectura nueva

Use una escala ordinal pequeña, como ausente, manejable, sustancial y bloqueante. Evite combinarlo todo en un único número decimal. Dos candidatos con el mismo total pueden contener riesgos muy distintos: uno puede exigir muchas proyecciones sencillas y el otro una sola invariante financiera bloqueante. La segunda controla la decisión.

El mejor primer límite suele tener escrituras cohesionadas y lecturas aburridas. Un grupo es dueño de sus actualizaciones y los consumidores externos se limitan en gran medida a mostrar o informar sobre sus datos. Esa forma admite un outbox, proyecciones y una superficie pequeña de comandos. El peor límite tiene pocas tablas evidentes, pero muchas lecturas de decisión actuales y escritores compartidos. Un esquema pequeño no implica poco acoplamiento.

Las ventanas temporales cambian el resultado. Analice periodos de negocio representativos, incluidas ejecuciones programadas y acciones poco frecuentes de operadores. Compare días normales con periodos de cierre o liquidación. Una matriz construida durante una tarde tranquila infravalora el acoplamiento. El análisis del código debe complementar la ventana enumerando puntos de entrada ausentes del tráfico capturado.

Mantenga visible la incertidumbre. Marque las tablas con trazas incompletas, nombres dinámicos, escritores externos o procedimientos desconocidos. Una arista sin resolver no vale cero. Yo retrasaría una decisión alrededor de una rutina de contabilización desconocida antes que confiar en un grafo limpio construido con pruebas parciales.

Demuestre el límite con comportamiento en sombra

Un límite gana confianza cuando los propietarios propuestos reproducen los resultados actuales con cargas registradas sin compartir escrituras. Antes de dirigir comandos de producción a servicios nuevos, ejecute la arquitectura candidata en sombra y compare sus transiciones de estado con las del original.

El arnés debe reproducir comandos o tráfico capturado con identificadores estables, observar efectos en la base y comparar resultados del negocio en lugar del orden físico de las filas. Normalice marcas de tiempo, identificadores generados y otros campos no deterministas. Compare totales, estados, hechos emitidos, clases de error y resultados de reinicio. Una diferencia necesita una explicación clasificada, no un porcentaje general de aprobación.

Incluya casos que ejerciten el límite:

1. comandos correctos con escrituras limitadas a un propietario
2. comandos rechazados después de una reserva o validación remota
3. reintentos tras tiempos de espera y entregas duplicadas
4. reinicio de lotes desde cada posición de control
5. datos de proyección desactualizados o ausentes

El tráfico registrado aporta realismo, pero rara vez contiene todos los fallos. Añada fallos controlados entre los pasos que antes compartían commit. Detenga al consumidor después de que escriba y antes de que confirme la recepción. Retrase una actualización de proyección. Repita un identificador de comando. Deje caducar una reserva mientras llega la confirmación. Estas pruebas muestran si el nuevo diseño tiene una recuperación explícita.

CodeHero usa un arnés de paridad contra tráfico de producción registrado cuando reescribe sistemas antiguos. Encaja con este trabajo porque los cambios de arquitectura solo son creíbles cuando el comportamiento sigue siendo responsable ante el original. Las pruebas deben ser legibles para los ingenieros del cliente: identidad de entrada, resultado antiguo, resultado nuevo, diferencias normalizadas y la regla usada para aceptarlas o rechazarlas.

No exija igualdad byte por byte cuando la migración cambia la arquitectura de forma intencionada. Exija igualdad para el comportamiento prometido y aceptación documentada para las diferencias previstas. Si cambia el orden de contabilización pero los saldos, referencias y reglas de recuperación siguen correctos, quizá no importe la secuencia física. Si un error se convierte en éxito después de un tiempo de espera, importa aunque el recuento final de tablas coincida.

La primera extracción debe eliminar un límite transaccional

Elija el primer servicio solo cuando pueda nombrar sus tablas, comandos, hechos publicados, lecturas transversales y reglas de recuperación. El equipo debe señalar cada antigua escritura entre límites y decir si se eliminó, se convirtió en un comando con propietario o se aceptó como restricción temporal de migración con una condición de salida fechada.

Uso una sola puerta de publicación: ninguna ruta de producción puede escribir tablas a ambos lados del límite propuesto. Las escrituras dobles temporales dentro de un adaptador de migración siguen contando como transversales. Necesitan idempotencia, comparación y un plan de eliminación, pero no demuestran propiedad independiente.

La secuencia de extracción sigue las pruebas. Primero imponga un escritor por tabla. Después sustituya las lecturas de visualización e informes por proyecciones o acceso transitorio aprobado. Traslade las lecturas de decisión a comandos del propietario o a protocolos explícitos de reserva. Por último, cambie los límites de despliegue y almacenamiento. Invertir el orden crea llamadas de red mientras el acoplamiento antiguo permanece.

Conserve las matrices de coescritura y lectura después de la extracción. Se convierten en controles de regresión. Un nuevo escritor compartido, un comando que comienza a leer estado remoto actual o un proceso que evita la API debe provocar una revisión. Los diagramas de arquitectura envejecen en silencio; las pruebas de acceso muestran la infracción.

Algunos sistemas contienen una invariante que debe seguir siendo local. Acepte ese resultado. Un servicio mayor con una transacción coherente es más barato y seguro que dos servicios unidos por llamadas síncronas, bloqueos distribuidos y reparaciones de operadores. El objetivo es el cambio independiente donde las reglas de negocio lo permiten, no el máximo número de desplegables.

Cuando las pruebas respaldan la separación, el límite deja de ser una opinión sobre sustantivos. Se convierte en una afirmación refutable: estas tablas cambian juntas, estas lecturas toleran este contrato, estos comandos conservan la invariante y estas pruebas de fallo demuestran recuperación independiente. Eso basta para pasar de un límite de taller a uno de producción.