Estoy seguro de que lo viste venir, "Depende".
Depende de todo. Y la solución para compartir datos de clientes para el departamento A puede ser completamente diferente para compartir datos de clientes con el departamento B.
Mi concepto favorito que ha surgido a lo largo de los años es el concepto de "Consistencia Eventual". El término proviene de Amazon hablando de sistemas distribuidos.
La premisa es que, si bien el estado de los datos en una empresa distribuida puede no ser perfectamente consistente ahora, "eventualmente" lo será.
Por ejemplo, cuando se actualiza un registro de cliente en el sistema A, los datos del cliente del sistema B ahora están obsoletos y no coinciden. Pero, "eventualmente", el registro de A se enviará a B a través de algún proceso. Entonces, eventualmente, las dos instancias coincidirán.
Cuando trabaja con un solo sistema, no tiene "EC", sino que tiene actualizaciones instantáneas, una única "fuente de la verdad" y, por lo general, un mecanismo de bloqueo para manejar las condiciones y los conflictos de la carrera.
Cuanto más capaces sean sus operaciones de trabajar con datos "EC", más fácil será separar estos sistemas. Un ejemplo simple es un almacén de datos utilizado por ventas. Usan el DW para ejecutar sus informes diarios, pero no ejecutan sus informes hasta la madrugada, y siempre miran los datos de "ayer" (o anteriores). Así que no hay necesidad de tiempo real para que el DW sea perfectamente consistente con el sistema de operaciones diarias. Es perfectamente aceptable que un proceso se ejecute, por ejemplo, al cierre de operaciones y mueva a lo largo de los días transacciones y actividades en masa en una sola operación de actualización grande.
Puede ver cómo este requisito puede resolver muchos problemas. No hay disputa por los datos transaccionales, no se preocupa de que algunos datos de informes cambien en medio de la acumulación de estadísticas porque el informe realizó dos consultas separadas a la base de datos en vivo. No es necesario que la charla de alto nivel absorba el procesamiento de la red y la CPU, etc. durante el día.
Ahora, ese es un ejemplo extremo, simplificado y muy tosco de EC.
Pero considere un gran sistema como Google. Como consumidor de la Búsqueda, no tenemos idea de cuándo o cuánto tiempo toma un resultado de búsqueda que Google recopila para saber cómo aparece en una página de búsqueda. 1 ms? 1s? 10s? 10 horas? Es fácil imaginar cómo, si accede a los servidores de la costa oeste de Google, es muy posible que obtenga un resultado de búsqueda diferente que si accede a los servidores de la costa este. En ningún momento estos dos casos son completamente consistentes. Pero en gran medida, en su mayoría son consistentes. Y para su caso de uso, sus consumidores no se ven realmente afectados por el retraso y la demora.
Considere el correo electrónico. A quiere enviar un mensaje a B, pero en el proceso el mensaje se enruta a través de los sistemas C, D y E. Cada sistema acepta el mensaje, asume toda la responsabilidad por él y luego se lo pasa a otro. El remitente ve que el correo electrónico sigue su camino. El receptor realmente no lo extraña porque no necesariamente sabe que viene. Por lo tanto, hay una gran ventana de tiempo que puede tomar para que ese mensaje se mueva a través del sistema sin que nadie se preocupe por saber qué tan rápido es.
Por otro lado, A podría haber estado hablando por teléfono con B. "Lo acabo de enviar, ¿ya lo recibiste? ¿Ahora? ¿Ahora? ¿Lo recibes ahora?"
Por lo tanto, existe algún tipo de nivel implícito subyacente de rendimiento y respuesta. Al final, "eventualmente", la bandeja de salida de A coincide con la bandeja de entrada de B.
Estos retrasos, la aceptación de datos obsoletos, ya sea de un día o de 1 a 5 segundos, son los que controlan el acoplamiento final de sus sistemas. Cuanto más laxo sea este requisito, más laxo será el acoplamiento y más flexibilidad tendrá a su disposición en términos de diseño.
Esto es cierto hasta los núcleos de su CPU. Las aplicaciones modernas, de múltiples núcleos y subprocesos múltiples que se ejecutan en el mismo sistema pueden tener diferentes vistas de los "mismos" datos, solo microsegundos desfasados. Si su código puede funcionar correctamente con datos potencialmente inconsistentes entre sí, entonces feliz día, se acelera. De lo contrario, debe prestar especial atención para asegurarse de que sus datos sean completamente consistentes, utilizando técnicas como calificaciones de memoria volátil o construcciones de bloqueo, etc. Todo lo cual, a su manera, cuesta rendimiento.
Entonces, esta es la consideración base. Todas las demás decisiones comienzan aquí. Responder esto puede decirle cómo particionar aplicaciones entre máquinas, qué recursos se comparten y cómo se comparten. Qué protocolos y técnicas están disponibles para mover los datos y cuánto costará en términos de procesamiento para realizar la transferencia. Replicación, balanceo de carga, uso compartido de datos, etc. etc. Todo basado en este concepto.
Editar, en respuesta al primer comentario.
Correcto, exacto. El juego aquí, por ejemplo, si B no puede cambiar los datos del cliente, ¿cuál es el daño con los datos del cliente cambiados? ¿Puedes "arriesgarte" a que esté desactualizado por un corto tiempo? Tal vez los datos de sus clientes lleguen lo suficientemente lento como para que pueda replicarlos de A a B inmediatamente. Digamos que el cambio se coloca en una cola que, debido al bajo volumen, se recoge rápidamente (<1 s), pero aun así estaría "fuera de transacción" con el cambio original, por lo que hay una pequeña ventana donde A tendría datos que B no.
Ahora la mente realmente comienza a dar vueltas. ¿Qué sucede durante esos 1 s de "retraso", cuál es el peor escenario posible? ¿Y puedes diseñar alrededor de eso? Si puede diseñar alrededor de un retraso de 1 s, puede diseñar alrededor de un retraso de 5 s, 1 m o incluso más. ¿Qué parte de los datos de los clientes utiliza realmente en B? Tal vez B sea un sistema diseñado para facilitar la preparación de pedidos del inventario. Es difícil imaginar que sea necesario algo más que simplemente una ID de cliente y tal vez un nombre. Solo algo para identificar groseramente para quién es el pedido mientras se ensambla.
El sistema de preparación de pedidos no necesariamente necesita imprimir toda la información del cliente hasta el final del proceso de selección y, para entonces, es posible que el pedido haya pasado a otro sistema que quizás esté más actualizado, especialmente con la información de envío, por lo que al final, el sistema de preparación de pedidos no necesita casi ningún dato del cliente. De hecho, podría INTEGRAR y desnormalizar la información del cliente dentro de la orden de recolección, por lo que no hay necesidad ni expectativa de sincronización posterior. Siempre que la identificación del cliente sea correcta (que nunca cambiará de todos modos) y el nombre (que cambia tan raramente que no vale la pena discutirlo), esa es la única referencia real que necesita, y todas sus boletas de selección son perfectamente precisas en el momento de creación.
El truco es la mentalidad, de romper los sistemas y centrarse en los datos esenciales que son necesarios para la tarea. Los datos que no necesita no necesitan ser replicados o sincronizados. La gente se irrita con cosas como la desnormalización y la reducción de datos, especialmente cuando pertenecen al mundo del modelado de datos relacionales. Y con razón, debe considerarse con cautela. Pero una vez que se distribuye, se ha desnormalizado implícitamente. Diablos, lo estás copiando al por mayor ahora. Por lo tanto, también puede ser más inteligente al respecto.
Todo esto se puede mitigar a través de procedimientos sólidos y una comprensión profunda del flujo de trabajo. Identifique los riesgos y elabore políticas y procedimientos para manejarlos.
Pero la parte difícil es romper la cadena con la base de datos central al principio e instruir a las personas que no pueden "tenerlo todo" como pueden esperar cuando tienen un almacén de información único, central y perfecto.
