Connect-GOLD

Feature #750

Updated by RishiKesh Tuniki 17 days ago

# Before Starting Let's Clarify this Queries: 
 **This is the architecture i found for Rabbit MQ** 
 ``` 
 RabbitMQ Server 
  ├── Virtual Host (vhost) 
  │      ├── Exchanges 
  │      ├── Queues 
  │      └── Bindings 
  │ 
  └── Connections (TCP) 
       └── Channels 
            └── (Used to publish / consume) 

 ``` 

 This what i found for our Requirements is this possible? 





 We need to build a **demo / proof of concept** to validate clinic-wise data synchronization using RabbitMQ. 

 In this setup: 

 * A **Windows Service** installed in the **clinic network** will act as a **producer** 
 * A **central server** will host **RabbitMQ**    and act as the **message broker** 
 * The server will create and manage **unique queues per clinic per API** and process messages independently 

 This demo will help validate: 

 1. Clinic-level isolation 
 2. API-level processing 
 3. Scalability and fault tolerance 

 ### 🎯 Objective 

 Demonstrate a working flow where: 

 1. Windows Service sends clinic-specific data to the server 
 2. Server routes messages using RabbitMQ 
 3. Unique queues are created per Clinic + API 
 4. Messages are consumed and processed successfully 

 ### 🧱 Proposed Architecture (High Level) 
 1️⃣ **Windows Service (Clinic Side)** 

 * Installed inside clinic network 
 * Acts as a stateless producer 
 * Sends data/events to RabbitMQ hosted on the server 
 * Publishes messages with: 

   * TenantId 
   * ClinicId 
   * API / Entity Type (Patient, Appointment, etc.) 

   ❗ Windows Service will NOT manage queues or channels 
 2️⃣ **Server Side (RabbitMQ)** 
 * RabbitMQ hosted centrally 
 * Responsible for: 
   * Exchange creation 
   * Queue creation 
   * Queue bindings 
 *Creates unique durable queues per: 
 ``` 
 Clinic + API 
 ``` 
 **Example Queue Naming:** 
 ``` 
 dentpal.clinic.{clinicId}.patient.sync 
 dentpal.clinic.{clinicId}.appointment.sync 
 dentpal.clinic.{clinicId}.payment.sync 

 ``` 
 3️⃣ **Consumer / Processor** 
 * Server-side consumers will: 

   * Listen to API-specific queues 
   * Process messages independently 
   * Acknowledge messages after successful processing 
 g 

 ### 🧪 Demo Scope 

 For this POC: 

 * One Windows Service instance 
 * One clinic (configurable ClinicId) 
 * At least 2 APIs 
   * Patient Sync 
   * Appointment Sync 

 * Basic logging for: 

   * Message published 
   * Message received 
   * Queue name used

Back