In this series, we’re exploring the architecture of a scalable healthcare booking system.

• Part 2 covered the system’s high-level structure and component interactions.
• Part 3 detailed the listing and searching mechanism using Elasticsearch, Django, and Kafka for fast, relevant results.

Now, in Part 4, we will shift our focus to the Role-Based Access Control (RBAC) mechanism. This part explains how the system ensures secure and restricted access to resources based on user roles (e.g., Customer, Partner, Admin). From the application layer to the database layer, this mechanism guarantees robust security and compliance by enforcing role-based rules.

Let’s dive into the specifics!

1. Frontend (React)

Purpose: Acts as the entry point for users, allowing them to interact with the system through the user interface.

Functionality:

• Handles input from users based on their role (Customer, Partner, Admin).
• Routes requests to the backend through API calls.

2. User Interface & API Routing

Purpose: Serves as the communication bridge between the frontend and backend.

Process:

• Captures user actions from the frontend.
• Routes them to the appropriate backend services through well-defined APIs.

3. Django Backend Services (Business Logic)

Purpose: Handles the core business logic, processing requests, and enforcing role-based access rules.

Key Responsibilities:

Define Roles:

• Roles include Customer, Partner, Admin, and anonymous users.

Role-Based Configuration:

• Uses Django’s built-in settings to configure roles and permissions.
• Ensures granular control over what actions each role can perform.

Permissions:

• Assigns permissions dynamically based on the user’s role.
• Example: Customers can book services, while partners manage their bookings and services.

4. Role-Based SQL Query Logic

Purpose: Constructs SQL queries tailored to the user’s role to enforce access restrictions at the database level.

Process:

Queries are dynamically constructed to include role-specific filters.

Example:

• Customers can only access their own bookings.
• Partners can view and manage services they own.

This ensures users can only interact with the data they are authorized to access.

5. Database Router

Purpose: Ensures queries are routed to the appropriate database based on the type of request.

Process:

• A Database Router checks the nature of the query (e.g., healthcare services or bookings).
• Routes the query to the corresponding database:
• HealthCare Services DB: Handles healthcare-related data.
• Booking DB: Manages booking and reservation data.

6. Databases (HealthCare Services DB & Booking DB)

Purpose: Stores and manages data securely, ensuring separation of concerns.

Details:

• HealthCare Services DB: Contains service-related data (e.g., providers, facilities).
• Booking DB: Stores data for bookings, cancellations, and customer transactions.

This diagram highlights how RBAC is implemented from the application layer to the database layer, ensuring secure and efficient access control.

Part 1: Building a Scalable Healthcare Booking Platform (Part 1): A System Story

Part 2: Building a Scalable Healthcare Booking Platform (Part 2): Technical Process Overview

Part 3: Building a Scalable Healthcare Booking Platform (Part 3): Listing Searching Mechanism