DSMS Deployment Diagrams

Because the DSMS needs three different servers—TOK, LON, NYK—each replicated across three physical machines, we end up running:

This satisfies the requirement that we have three replicated copies for each city code: (TOK1, TOK2, TOK3), (LON1, LON2, LON3), and (NYK1, NYK2, NYK3). Below are two diagrams illustrating how Machine 1 differs from a “plain” machine (Machine 2 or Machine 3).


1. Machine 1 - Detailed Implementation Diagram

Machine 1 hosts:

Machine 1 Deployment
flowchart TB subgraph Machine1 [Machine 1] direction TB FE(Front End):::fe SQ(Sequencer):::seq subgraph DSMS_Processes direction TB TOK1(TOK Instance - M1):::replica RMTOK1(RM TOK - M1):::rm LON1(LON Instance - M1):::replica RMLON1(RM LON - M1):::rm NYK1(NYK Instance - M1):::replica RMNYK1(RM NYK - M1):::rm end end %% Arrows for internal communication FE -- requests --> SQ SQ -- seq. msgs --> TOK1 SQ -- seq. msgs --> LON1 SQ -- seq. msgs --> NYK1 %% Replicas -> FE TOK1 -- results --> FE LON1 -- results --> FE NYK1 -- results --> FE %% RM internal signals FE -- crash/fault info --> RMTOK1 FE -- crash/fault info --> RMLON1 FE -- crash/fault info --> RMNYK1 %% Relationship between RM and its instance RMTOK1 -- manages --> TOK1 RMLON1 -- manages --> LON1 RMNYK1 -- manages --> NYK1 classDef fe fill:#ADE7FF,stroke:#333,stroke-width:1px classDef seq fill:#FFD585,stroke:#333,stroke-width:1px classDef replica fill:#C7FFC7,stroke:#333,stroke-width:1px classDef rm fill:#FFC7C7,stroke:#333,stroke-width:1px

Key Points:


2. Machine 2 (or Machine 3) - Detailed Implementation Diagram

Machines 2 and 3 do not host the FE or Sequencer. They only run:

That way, each city code has a replica on Machine 1, 2, and 3. The Sequencer on Machine 1 sends requests to all nine processes (3 per machine).

Machine 2 or 3 Deployment
flowchart TB subgraph MachineX [Machine 2 or Machine 3] direction TB subgraph DSMS_Processes direction TB TOKx(TOK Instance - M2/M3):::replica RMTOKx(RM TOK - M2/M3):::rm LONx(LON Instance - M2/M3):::replica RMLONx(RM LON - M2/M3):::rm NYKx(NYK Instance - M2/M3):::replica RMNYKx(RM NYK - M2/M3):::rm end end %% Arrows from Sequencer (on Machine 1) SQ1(Sequencer - M1):::seq SQ1 -- seq. msgs --> TOKx SQ1 -- seq. msgs --> LONx SQ1 -- seq. msgs --> NYKx %% Replicas -> FE on M1 FE1(Front End - M1):::fe TOKx -- results --> FE1 LONx -- results --> FE1 NYKx -- results --> FE1 %% Crash/fault notifications FE1 -- crash/fault info --> RMTOKx FE1 -- crash/fault info --> RMLONx FE1 -- crash/fault info --> RMNYKx %% RM manages the local instance RMTOKx -- manages --> TOKx RMLONx -- manages --> LONx RMNYKx -- manages --> NYKx classDef fe fill:#ADE7FF,stroke:#333,stroke-width:1px classDef seq fill:#FFD585,stroke:#333,stroke-width:1px classDef replica fill:#C7FFC7,stroke:#333,stroke-width:1px classDef rm fill:#FFC7C7,stroke:#333,stroke-width:1px

Key Points:


Summary

In this final deployment:

These two diagrams illustrate the difference between the “primary” machine that hosts the FE + SQ + 3 city servers, versus the “secondary” machines that only host the 3 city servers (TOK, LON, NYK) and their RMs.