RE_Documents/RE Dealer onboarding preliminary Syastem.md

RE Workflow Solutions
Preliminary System Design, Security & Technical
Document
Preliminary Approach & Solution Analysis Document
25 - August- 2025
Version 1. 0
Contents
1 Objective
2 Problem Statement
3 System Requirements
3.1 Functional Requirements
3.2 Non-Functional Requirements
4 Bird Eye View
5 System Design
6 System Design Explanation
6.1 User Authentication & Access Flow
6.1.1 Step-by-Step Authentication Flow
6.2 API Driven Framework
6.3 Frontend Layer (React.js)
6.4 Backend Service (Node.js)
6.5 Data Handling & Storage
7 Scalability & Performance
8 DPDP Act Compliance
9 Security Requirements and Technical Implementation
9.1 Input Validation and Sanitization
9.2 Secure File Handling
9.3 DDoS and API Rate Limiting
10 Monitoring & Maintenance
11 Camunda Support
1 Objective
Automate the Dealer Development process to streamline prospect applications, vacancy checks,
approvals, and LOI issuance. Enhance efficiency and scalability for 1,000 users, ensuring a
seamless dealer onboarding experience. Maintain DPDP compliance with secure, reliable
processes, reducing manual effort and improving decision-making for stakeholders.

Additionally, the review and approval process differs from scenario to scenario, so the system
should be dynamically capable enough to cater this need.

2 Problem Statement
The absence of a Dealer Development automation system creates significant challenges in
managing the dealer onboarding process efficiently and securely. Currently, manual processes
for handling prospect applications, vacancy checks, approvals, and LOI issuance are time-
consuming, error-prone, and lack scalability.

This leads to delays in processing applications, inconsistent data handling, and difficulties in
generating timely reports, such as daily web lead summaries and location-wise details.
Additionally, the lack of automated security measures increases the security risk of non-
compliance with Digital Personal Data Protection (DPDP) regulations, particularly for sensitive
prospect data. Without a centralized system, stakeholder coordination (DD Lead, RBM, ZBH,
NBH) is fragmented, hindering decision-making and impacting the overall dealer onboarding
experience.

3 System Requirements
3.1 Functional Requirements
Dealer Onboarding Workflow
Capture enquiries via form, validate against opportunity list.
Automated emails, reminders, scoring, and top-candidate shortlisting.
Multi-level approvals (ASM → ZM → RBM → ZBH → NBH).
Profile sheet submission, KT evaluations, and final LOI issuance.
Custom Approval Workflows: Admin can configure different approval chains
depending on region size (e.g., simpler workflows for smaller regions, extended
hierarchies for larger regions).
Dealer Exit Workflow
Resignation: Letter submission, ASM template, approvals (ZBH → DD Lead → NBH),
legal concurrence, dealer acknowledgment.
Termination: Record reasons, prepare docs, legal show-cause notice (15-day timer),
approvals (ZBH → DD Lead → NBH → CCO → CEO), final termination letter.
Full & Final Settlement: Coordinate with stakeholders, reconcile dues, block
SAP/MSD codes, Finance AR calculates F&F, dealer acceptance or legal escalation.
Automation
Automated notifications (acknowledgments, reminders, approvals, LOI, F&F).
SLA-driven reminders (Day 2, Day 5, 15-day cutoffs).
Reminders can be customized in terms of duration frequency vs levels.
Reporting
Every user can login and view the Dashboard & quick reports
Access Control
Role-based access for Admin, ASM, ZM, RBM, ZBH, NBH, CCO.
Regional scoping and complete audit logs.
3.2 Non-Functional Requirements
Scalability : Support 1 0 ,000 total users and 200 concurrent users.
Performance : Achieve <2s latency for most operations during peak hours (9 AM–5 PM
IST).
Availability : Ensure 99.9% uptime.
Security : Comply with DPDP Act, 2023, with encryption and RBAC.
Reliability : Maintain data consistency and fault tolerance across workflows.
4 Bird Eye View

The Bird Eye View provides a high-level architectural overview of the RE Workflow Application, illustrating the key components, user interactions, and data flow patterns that form the foundation of the entire system.

## 4.1 System Architecture Overview

The RE Workflow App follows a centralized, secure, and scalable architecture designed to serve multiple user roles while maintaining strict security protocols and efficient data management.

### 4.1.1 User Ecosystem
The system serves a diverse range of stakeholders across the Royal Enfield dealer development hierarchy:

**Primary User Roles:**
- **Super Admin**: System administrators with full access and configuration rights
- **ASM (Area Sales Manager)**: Regional sales management and dealer oversight
- **ZM (Zone Manager)**: Zone-level management and approval authority
- **RBM (Regional Business Manager)**: Regional business strategy and decision-making
- **DD (Dealer Development)**: Dealer development specialists and coordinators
- **NBH (National Business Head)**: Strategic oversight and final approvals
- **Finance**: Financial approval and settlement processing

### 4.1.2 Authentication & Authorization Flow

**RE Bridge Centralised SSO Integration**
- Single Sign-On (SSO) authentication through Royal Enfield's centralized identity management system
- Seamless integration with existing corporate Active Directory infrastructure
- Role-based access control (RBAC) ensuring users access only authorized functions
- Session management with automatic timeout and security token refresh

**Authentication Process:**
1. User initiates login through RE Bridge Centralised SSO
2. Credentials validated against corporate Active Directory
3. Role-based permissions assigned and validated
4. Secure session established with appropriate access levels
5. User redirected to RE Workflow App with authenticated access

## 4.2 Core System Components

### 4.2.1 Security Layer
The security layer serves as the primary gatekeeper for all system access:

**Security Functions:**
- **Authentication Verification**: Validates user credentials and session tokens
- **Authorization Control**: Enforces role-based access permissions
- **Session Management**: Maintains secure user sessions with timeout controls
- **Audit Logging**: Records all access attempts and security events
- **Data Protection**: Ensures compliance with DPDP Act requirements

**Security Protocols:**
- TLS 1.3 encryption for all data transmission
- Multi-factor authentication for sensitive operations
- Regular security token rotation and validation
- Comprehensive audit trails for compliance reporting

### 4.2.2 Core Business & Services Modules
The heart of the application where all business logic and workflow processing occurs:

**Primary Modules:**
- **Dealer Onboarding Management**: Complete lifecycle management from application to LOI issuance
- **Custom Workflow Engine**: Dynamic workflow configuration and execution
- **Dealer Resignation Processing**: Structured resignation and termination workflows
- **Full & Final Settlement**: Financial settlement calculation and processing
- **Dashboard & Analytics**: Real-time reporting and performance metrics
- **Document Management**: Secure document storage, retrieval, and version control

**Business Process Integration:**
- Automated workflow orchestration
- Multi-level approval chain management
- SLA tracking and enforcement
- Real-time status updates and notifications
- Integration with external systems (SAP, DMS, Email)

### 4.2.3 Database Layer (PostgreSQL)

**Primary Database Functions:**
- **Transactional Data Storage**: ACID-compliant data persistence for all business operations
- **User Management**: User profiles, roles, and permission storage
- **Workflow State Management**: Process instance tracking and state persistence
- **Document Metadata**: File references and metadata storage
- **Audit Trail Storage**: Comprehensive logging of all system activities

**Database Architecture:**
- **Primary Instance**: Handles all write operations and critical transactions
- **Read Replica**: Optimizes reporting and analytics queries
- **Backup & Recovery**: Automated backup with point-in-time recovery capability
- **Performance Optimization**: Query optimization and indexing strategies

### 4.2.4 Supporting Services

**Monitoring Services:**
- **System Health Monitoring**: Real-time system performance tracking
- **Business Metrics Tracking**: KPI monitoring and alerting
- **Capacity Planning**: Resource utilization monitoring and forecasting
- **SLA Compliance**: Service level agreement monitoring and reporting

**Logging Services:**
- **Application Logging**: Comprehensive application event logging
- **Security Logging**: Authentication, authorization, and security event logging
- **Performance Logging**: System performance and bottleneck identification
- **Compliance Logging**: DPDP Act compliance and audit trail maintenance

### 4.2.5 Cloud Storage Integration

**Storage Functions:**
- **Document Archive**: Secure storage for all business documents and files
- **Backup Storage**: Automated backup storage for disaster recovery
- **Media Storage**: Image and document storage for dealer applications
- **Compliance Storage**: Long-term storage for audit and compliance records

**Storage Features:**
- **Encryption at Rest**: AES-256 encryption for all stored data
- **Access Control**: Role-based access to stored documents
- **Version Control**: Document versioning and change tracking
- **Retention Policies**: Automated data retention and archival policies

## 4.3 Data Flow Architecture

### 4.3.1 User Interaction Flow
1. **Authentication**: User → RE Bridge Centralised SSO → Security Layer
2. **Authorization**: Security Layer validates permissions and grants access
3. **Business Processing**: User interacts with Core Business & Services Modules
4. **Data Operations**: Business modules interact with PostgreSQL Database
5. **Document Management**: File operations handled through Cloud Storage
6. **Monitoring & Logging**: All activities logged and monitored continuously

### 4.3.2 System Integration Flow
1. **External System Integration**: SAP, DMS, and third-party system connectivity
2. **Data Synchronization**: Real-time data sync between systems
3. **Notification Delivery**: Email, SMS, and push notification processing
4. **Report Generation**: Automated report creation and distribution
5. **Backup & Recovery**: Continuous backup and disaster recovery processes

## 4.4 Scalability and Performance Considerations

### 4.4.1 Horizontal Scaling
- **Load Distribution**: Multiple instances of Core Business & Services Modules
- **Database Scaling**: Read replica distribution for improved query performance
- **Storage Scaling**: Cloud storage auto-scaling based on demand
- **Caching Strategy**: Redis caching for frequently accessed data

### 4.4.2 Performance Optimization
- **Connection Pooling**: Optimized database connection management
- **Query Optimization**: Efficient database query design and indexing
- **CDN Integration**: Content delivery network for static assets
- **Asynchronous Processing**: Background job processing for non-critical operations

## 4.5 Security and Compliance

### 4.5.1 Data Protection
- **Encryption**: End-to-end encryption for all data transmission and storage
- **Access Control**: Multi-layered access control with role-based permissions
- **Audit Trails**: Comprehensive logging for compliance and security monitoring
- **Data Localization**: Compliance with data residency requirements

### 4.5.2 DPDP Act Compliance
- **Data Minimization**: Collection of only necessary personal data
- **Consent Management**: Explicit consent tracking and management
- **Data Subject Rights**: User access and data portability capabilities
- **Breach Notification**: Automated breach detection and notification systems

## 4.6 System Dependencies and Integration Points

### 4.6.1 External Dependencies
- **RE Bridge Centralised SSO**: Authentication and authorization services
- **Active Directory**: User identity and role management
- **SAP System**: Dealer master data and financial processing
- **DMS System**: Document management and archival services
- **Cloud Storage**: Scalable document and file storage

### 4.6.2 Internal Dependencies
- **PostgreSQL Database**: Primary data storage and transaction management
- **Monitoring Services**: System health and performance monitoring
- **Logging Services**: Application and security event logging
- **Notification Services**: Multi-channel communication capabilities

This Bird Eye View establishes the foundation for the detailed system design, ensuring that all architectural decisions align with the high-level requirements for security, scalability, and user experience.

5 System Design

The RE Workflow Solution follows a modern, scalable microservices architecture designed to handle high-volume dealer onboarding processes with enterprise-grade security and performance. The system is built on a multi-layered architecture that ensures separation of concerns, scalability, and maintainability.

## 5.1 Architecture Overview

The system architecture consists of the following key layers:

### 5.1.1 Access and Authentication Layer
- **Admin Web App**: Browser-based access portal for all users
- **WAF Firewall**: Web Application Firewall providing DDoS protection and security filtering
- **API Gateway (Kong)**: Centralized entry point handling authentication, rate limiting, and request routing

### 5.1.2 Core Business Services Layer
- **Schedulers**: Task scheduling and automation services
- **Core Business Modules**: Main application logic for dealer processes
- **Logstash**: Log collection and processing

### 5.1.3 Data and Storage Layer
- **PostgreSQL Database**: Primary data store with read replicas
- **Redis Cache**: Session management and performance optimization
- **Object Storage**: Document and file management

### 5.1.4 Monitoring and Operations Layer
- **Grafana & Prometheus**: Metrics collection and visualization
- **ELK Stack**: Logging, search, and analytics
- **Message Queue**: Asynchronous processing and notifications

### 5.1.5 External Integration Layer
- **Notification Services**: Email, SMS, and push notifications
- **External APIs**: SAP, DMS, and third-party integrations

## 5.2 Detailed Component Architecture

### 5.2.1 API Gateway (Kong) Configuration

The API Gateway serves as the single entry point and implements:

**Rate Limiting**
- IP-based rate limiting: 100 requests/minute per IP
- User-based rate limiting: 500 requests/minute per authenticated user
- Whitelist support for trusted sources

**Metric Collection**
- Request/response metrics
- Performance monitoring
- User activity tracking
- API usage analytics

**Header Transformation**
- Security header injection
- Request/response header standardization
- CORS policy enforcement

**Error Handling**
- Centralized error response formatting
- Error code standardization
- Detailed logging for debugging

### 5.2.2 Authentication Flow Architecture

**SSO Integration Flow:**
1. User accesses portal via browser
2. WAF validates and filters request
3. API Gateway checks for active session
4. If no session, redirect to Identity Provider (MS AD/Okta)
5. IdP validates credentials against Active Directory
6. Authorization code returned to portal
7. Portal exchanges code for access/refresh tokens
8. Local session created with secure cookie
9. User granted access to application

**Session Management:**
- Secure HTTP-only cookies with SameSite protection
- Session timeout: 8 hours of inactivity
- Automatic token refresh using refresh tokens
- Multi-device session tracking

### 5.2.3 Core Business Modules

**Dealer Application & Onboarding Module**
- Application form processing and validation
- Automated scoring and ranking algorithms
- Multi-level approval workflow management
- Document collection and verification
- LOI/LOA generation and distribution

**Custom Workflow Module**
- Dynamic workflow configuration
- Template-based workflow creation
- Regional customization support
- Approval chain management
- SLA tracking and enforcement

**Dealer Resignation Module**
- Resignation request processing
- Template-based letter generation
- Multi-level approval workflows
- Legal concurrence management
- Dealer acknowledgment tracking

**Full & Final Settlement Module**
- F&F calculation engine
- Stakeholder coordination
- SAP integration for code blocking
- Finance AR integration
- Legal escalation management

**Dashboard, Reports & Analytics Module**
- Real-time dashboard updates
- Custom report generation
- Performance metrics and KPIs
- Export functionality (PDF, Excel, CSV)
- Data visualization and charts

### 5.2.4 Database Architecture (PostgreSQL)

**Primary Database Instance**
- Write operations and transactions
- ACID compliance
- Data integrity enforcement
- Backup and recovery

**Read Replica Instance**
- Read-only queries for reporting
- Load distribution
- Performance optimization
- Real-time synchronization

**Write-Ahead Logging (WAL)**
- Transaction durability
- Point-in-time recovery
- Replication support
- Crash recovery

**Database Access Layer (DAL)**
- Connection pooling (max 100 connections)
- Query builder with SQL injection protection
- Database error handling and retry logic
- Performance monitoring and optimization

### 5.2.5 Caching Strategy (Redis)

**Session Cache**
- User session storage
- Authentication tokens
- Permission and role caching
- TTL: 8 hours

**Application Cache**
- Frequently accessed data (towns, dealer codes)
- Master data caching
- Report result caching
- TTL: 24 hours

**Performance Cache**
- API response caching
- Database query result caching
- Static content caching
- TTL: 1 hour

### 5.2.6 Outbound Network Layer

**External API Integration**
- SAP system integration for dealer creation
- DMS integration for document management
- Third-party service integrations

**Circuit Breaker Pattern**
- Automatic failure detection
- Fallback mechanisms
- Recovery testing
- Service degradation handling

**Retry Logic**
- Exponential backoff for failed requests
- Maximum retry count: 3
- Timeout configuration: 30 seconds
- Network error handling

**Response Validation**
- Schema validation for external responses
- Data integrity checks
- Error response handling
- Logging and monitoring

### 5.2.7 Monitoring and Alerting

**Metrics Collection (Prometheus)**
- System performance metrics
- Application performance indicators
- Business process metrics
- Custom KPI tracking

**Visualization (Grafana)**
- Real-time dashboards
- Historical trend analysis
- Alert visualization
- Custom metric displays

**Alerting System**
- Threshold-based alerts
- Anomaly detection
- Escalation procedures
- Integration with notification services

### 5.2.8 Logging and Analytics (ELK Stack)

**Log Collection (Logstash)**
- Application log aggregation
- System log collection
- Error log processing
- Performance log analysis

**Search and Analytics (ElasticSearch)**
- Log indexing and search
- Performance analytics
- Error pattern analysis
- Compliance audit trails

**Visualization (Kibana)**
- Log visualization dashboards
- Performance trend analysis
- Error investigation tools
- Compliance reporting

### 5.2.9 Notification Services

**Email Notifications**
- SMTP gateway integration
- Template-based email generation
- Delivery tracking and retry
- Bounce handling

**SMS Notifications**
- SMS gateway integration
- Bulk SMS capabilities
- Delivery confirmation
- Cost optimization

**Push Notifications**
- Firebase integration
- Mobile app notifications
- Web push notifications
- Delivery analytics

## 5.3 Data Flow Architecture

### 5.3.1 Request Processing Flow

1. **User Request**: Browser → WAF → API Gateway
2. **Authentication**: API Gateway → IdP → Active Directory
3. **Authorization**: Role validation → Permission check
4. **Routing**: Load balancer → Core business modules
5. **Processing**: Business logic → Database operations
6. **Response**: Data retrieval → Cache check → Response formatting
7. **Delivery**: API Gateway → Browser

### 5.3.2 Asynchronous Processing Flow

1. **Event Trigger**: Business process completion
2. **Message Queue**: Event queuing for processing
3. **Background Jobs**: Email sending, report generation
4. **External Integration**: SAP updates, document processing
5. **Notification**: User notifications via multiple channels

### 5.3.3 Data Synchronization Flow

1. **Primary Write**: Database write operation
2. **WAL Generation**: Write-ahead log creation
3. **Replica Sync**: Real-time synchronization to read replica
4. **Cache Update**: Redis cache invalidation/update
5. **Index Update**: Search index refresh

## 5.4 Security Architecture

### 5.4.1 Network Security
- WAF protection against common attacks
- TLS 1.3 encryption for all communications
- Network segmentation and firewall rules
- VPN access for administrative functions

### 5.4.2 Application Security
- Input validation and sanitization
- SQL injection prevention
- XSS protection
- CSRF token implementation

### 5.4.3 Data Security
- AES-256 encryption for data at rest
- Field-level encryption for sensitive data
- Secure key management
- Data masking for non-production environments

### 5.4.4 Access Control
- Role-based access control (RBAC)
- Principle of least privilege
- Multi-factor authentication for sensitive roles
- Session management and timeout

## 5.5 Scalability and Performance

### 5.5.1 Horizontal Scaling
- Load balancer distribution
- Database read replicas
- Microservice architecture
- Container orchestration support

### 5.5.2 Performance Optimization
- Redis caching strategy
- Database query optimization
- CDN integration for static assets
- Connection pooling

### 5.5.3 Monitoring and Metrics
- Real-time performance monitoring
- Capacity planning metrics
- SLA tracking and reporting
- Performance bottleneck identification

## 5.6 Disaster Recovery and Backup

### 5.6.1 Backup Strategy
- Daily automated backups
- Point-in-time recovery capability
- Cross-region backup replication
- Backup testing and validation

### 5.6.2 High Availability
- Multi-AZ deployment
- Database failover automation
- Service redundancy
- Health check monitoring

### 5.6.3 Recovery Procedures
- RTO: 4 hours maximum
- RPO: 1 hour maximum
- Automated recovery testing
- Documentation and runbooks

6 System Design Explanation
6.1 User Authentication & Access Flow
The system leverages Royal Enfield’s existing Active Directory (AD) via an Identity Provider
(IdP) (Azure AD / ADFS) for authentication. This means that user identity and credentials are not
managed within the portal but by AD, ensuring consistency with corporate policies.

6.1.1 Step-by-Step Authentication Flow
First-Time Access

A user navigates to the portal (e.g., https://dd-portal.re.com/).
The portal checks for an active application session (secure session cookie sid). If
absent/expired, the user is redirected to the IdP’s /authorize endpoint.
The IdP validates the user credentials against AD
Upon successful authentication, the IdP (Identity Provider) redirects back to the portal’s
callback URL with an authorization code.
The portal backend exchanges the authorization code with the IdP’s /token endpoint
over HTTPS. Response includes: ID Token (identity claims), Access Token, and Refresh
Token.
The ID Token is validated using IdP’s public keys and claims are extracted (user, roles,
groups).
A secure application session is created (stored locally), and an opaque sid cookie is set in
the user’s browser.
User gains access to the portal and their dashboard.
Subsequent Access

On the next request, the browser presents the sid cookie.
If the session is still valid, the request is allowed directly.
If expired, the portal redirects to the IdP.
If the IdP SSO session is still valid, a new token is issued silently via Refresh Token (no
login prompt).
If IdP SSO is also expired, the user must re-enter credentials.
6.2 API Driven Framework
Expose all business capabilities (Applications, Evaluations, Approvals, Documents, Notifications,
F&F, Reports) as versioned, secure APIs. This decouples frontends (web portal today, mobile app
tomorrow) from backend services and enables internal/partner integrations without
re-engineering.

6.3 Frontend Layer (React.js)
The frontend of the Dealer Development Automation system will be a web portal accessible to
applicants and internal staff. It will provide intuitive forms for dealer applications ,
interactive dashboards for approvals and evaluations , and comprehensive reporting
views (daily summaries, location-wise performance, F&F status). The portal will communicate
exclusively with backend services through the API Gateway , ensuring a clean separation of
concerns and enabling an API-driven architecture.
The frontend will be developed using ReactJS , chosen for its strong ecosystem and wide
community support available. React allows us to build highly responsive UIs where approval
workflows, reminders, and multi-level evaluation forms can be represented as reusable
components, reducing development effort and improving maintainability.

6.4 Backend Service (Node.js)
Node.js has become one of the most widely adopted backend technologies because of its API
First, event-driven, non-blocking I/O architecture , which makes it highly efficient at handling
thousands of concurrent API calls, webhooks, and real-time events with minimal resource usage.
The combination of performance, developer productivity, ecosystem maturity, and platform
support makes Node.js not just a trending choice, but a future-proof technology for building
scalable, API-driven enterprise systems like the Dealer Development Automation platform

6.5 Data Handling & Storage
PostgreSQL : Database: Primary transactional store; read replica for reporting.
Redis Cache : Session storage, rate limiting, reminder state.
Object Storage : Legal and operational document archive over cloud storage
Audit Logs : Immutable records of all approvals, actions, and data changes for
compliance.
Monitoring & Logging : Prometheus/Grafana for metrics, ELK/Cloud Logging for logs.
7 Scalability & Performance
Load Handling : 1,000 requests/minute (200 users × 5 calls/minute).
API Gateway : Handles rate limiting, load balancing, routing.
Database :
PostgreSQL: Read replicas for queries.
Object Storage: Scalable for documents.
Caching : Redis for frequent queries (e.g., user roles, town lists).
Asynchronous Processing : Message Queue for emails and integrations.
Microservice-ready design allows scaling each service independently.
Event-driven architecture ensures async notifications and workflows.
Configurable workflows support regional customization.
Mobile-ready design with JWT support for future app extensions.
Libraries & Dependencies We ensure to use the libraries which are having healthy
cadence & footprint, check known issues on it’s GIT, Licence, ran by foundation or single
person & GIT Insights
8 DPDP Act Compliance
The system adheres to the Digital Personal Data Protection Act, 2023 , with the following measures:

Data Minimization : Collect only necessary data (e.g., dealer name, contact, financial
details).
Consent Management : Obtain explicit consent via web forms, stored in a DB
Data Subject Rights : Provide interface for dealers to access their data.
Data Security : Use TLS 1.3 for data in transit and AES-256 for data at rest.
Data Localization : Deploy databases and storage in India-based cloud regions.
Breach Notification : Alerts within 72 hours of a data breach.
Audit Trails : Log all data access and modifications for compliance audits.
9 Security Requirements and Technical Implementation
DPDP-Specific :
Data Localization : Deploy in India-based regions.
Consent Management : Store consent records, provide opt-out.
Breach Notification : Alerts within 72 hours
Audit Trails : Log data access in ELK Stack.
General Security :
Encryption : TLS 1.3, AES-256.
WAF : Deploy cloud specific WAF.
MFA : Enforce for sensitive roles.
Secure APIs : Use API keys, OAuth tokens, rate limiting.
API Gateway / Reverse Proxy: TLS termination, rate limiting, request validation,
and routing.
Network Firewall: Ensures only HTTPS (443) is exposed externally; internal DBs
remain private.
Secrets Management: All API keys, DB credentials, and OAuth secrets stored in
KMS/Vault.
9.1 Input Validation and Sanitization
Requirement : Mitigate injection attacks (e.g., SQL injection, Cross-Site Scripting [XSS])
on user inputs such as questionnaire responses, comments, and custom flow
configurations.
Rationale : Malicious inputs could execute unauthorized scripts or corrupt data,
particularly in the platform’s interactive forms and dynamic workflows.
Risk Level : Medium
Implementation Strategy :
Validation : Enforce input schemas in Node.js, validating data types (e.g., email
regex, numeric scores) before processing.
9.2 Secure File Handling
Requirement : Safeguard uploaded files (e.g., business plans, financial documents, legal
papers) against unauthorized access, tampering, or malware.
Rationale : Exposure of confidential business data could disrupt the onboarding process
or lead to legal liabilities, given the platform’s document-centric nature.
Risk Level : High
Implementation Strategy :
Storage : Utilize a secure object storage service (e.g., AWS S3 with SSE-KMS) with
private access policies and server-side encryption.
Access : Generate time-bound pre-signed URLs (e.g., 300-second expiration) via
Node.js routes, authenticated with user tokens.
9.3 DDoS and API Rate Limiting
Requirement : Defend against Distributed Denial of Service (DDoS) attacks and API abuse
during peak onboarding activity.
Rationale : High-traffic features (e.g., report downloads, progress sharing) are vulnerable
to overload, potentially disrupting service availability.
Risk Level : Medium
Implementation Strategy :
Rate Limiting : Configure express-rate-limit in Node.js to cap API requests at 100
per minute per IP, with whitelisting for trusted sources.
DDoS Mitigation : Integrate a CDN with Web Application Firewall (WAF)
capabilities (e.g., Cloudflare) to filter malicious traffic and distribute load.
10 Monitoring & Maintenance
Monitoring : Prometheus for metrics, Grafana for dashboards.
Logging : ELK Stack for DPDP-compliant audits.
Maintenance : CI/CD pipeline with Jenkins/GitHub Actions.
11 Camunda Support
Camunda provides APIs to let external applications start, advance, and complete workflow steps.
In Camunda 7 , this is done via the REST API
(e.g., POST /process-definition/key/dealer_application/start to start a new dealer
application flow). In Camunda 8 (Zeebe engine) , APIs are available as gRPC client libraries (Java,
Node.js, Go) or via a REST gateway ; for example, a Node.js service can
call zbc.createProcessInstance({ bpmnProcessId: "dealer_application_v1",
variables: { applicantId: "APP123" } }) whenever a dealer submits an application form.
This integration allows the process instance to flow through approval tasks (ASM → ZM → NBH),
with each stage visible in Camunda Operate , and bottlenecks/heatmaps available in Camunda
Optimize. Camunda offers a free Community Edition (open source) for self-managed setups, and
a SaaS version (Camunda 8) with usage-based pricing; as of 2025, SaaS plans start with a free
tier (up to 5 users and limited usage) , then scale to Team/Enterprise plans based on process
instance volume, storage, and enterprise features like Optimize, Tasklist, and SLA support.