AHMET YILMAZ
b3fff546e9
Some checks failed
System Monitoring / Health Checks (push) Has been cancelled
System Monitoring / Performance Monitoring (push) Has been cancelled
System Monitoring / Database Monitoring (push) Has been cancelled
System Monitoring / Cache Monitoring (push) Has been cancelled
System Monitoring / Log Monitoring (push) Has been cancelled
System Monitoring / Resource Monitoring (push) Has been cancelled
System Monitoring / Uptime Monitoring (push) Has been cancelled
System Monitoring / Backup Monitoring (push) Has been cancelled
System Monitoring / Security Monitoring (push) Has been cancelled
System Monitoring / Monitoring Dashboard (push) Has been cancelled
System Monitoring / Alerting (push) Has been cancelled
Security Scanning / Dependency Scanning (push) Has been cancelled
Security Scanning / Code Security Scanning (push) Has been cancelled
Security Scanning / Secrets Scanning (push) Has been cancelled
Security Scanning / Container Security Scanning (push) Has been cancelled
Security Scanning / Compliance Checking (push) Has been cancelled
Security Scanning / Security Dashboard (push) Has been cancelled
Security Scanning / Security Remediation (push) Has been cancelled
119 lines
3.8 KiB
Markdown
119 lines
3.8 KiB
Markdown
# Research Findings
|
|
|
|
## Multi-Tenant Architecture Decisions
|
|
|
|
### Database Multi-Tenancy Strategy
|
|
**Decision**: PostgreSQL with Row-Level Security (RLS)
|
|
**Rationale**:
|
|
- Provides strong data isolation between tenants
|
|
- Supported by Django and FastAPI
|
|
- Built-in security at database level
|
|
- Cost-effective for 100 tenant scale
|
|
- Malaysian data residency compliance
|
|
|
|
**Alternatives considered**:
|
|
- Separate databases per tenant: Too expensive at scale
|
|
- Schema-based tenancy: Complex management and migration challenges
|
|
- Application-level filtering: Higher security risk
|
|
|
|
### Backend Framework Selection
|
|
**Decision**: Django + Django REST Framework
|
|
**Rationale**:
|
|
- Built-in admin interface for back office
|
|
- Mature multi-tenant packages (django-tenants)
|
|
- Strong ORM for complex data models
|
|
- Authentication system built-in
|
|
- Malaysian developer community support
|
|
|
|
**Alternatives considered**:
|
|
- FastAPI: Better performance but less built-in admin
|
|
- Flask: Too minimal for complex business logic
|
|
- Node.js: Not ideal for Malaysian enterprise market
|
|
|
|
### Frontend Framework Selection
|
|
**Decision**: Next.js with TypeScript
|
|
**Rationale**:
|
|
- Server-side rendering for SEO
|
|
- Type safety for large codebase
|
|
- Malaysian SME users need fast, responsive UI
|
|
- Strong component ecosystem
|
|
- Easy deployment with Docker
|
|
|
|
### Authentication Strategy
|
|
**Decision**: Multi-auth approach with Django Allauth
|
|
**Rationale**: Supports all required methods:
|
|
- Email/password with MFA
|
|
- SSO integration
|
|
- OAuth providers
|
|
- Custom Malaysian National ID integration (future)
|
|
|
|
### Payment Processing
|
|
**Decision**: Stripe + Midtrans dual integration
|
|
**Rationale**:
|
|
- Stripe: International standard, subscription management
|
|
- Midtrans: Malaysian payment methods (FPX, e-wallets)
|
|
- Both support recurring billing and one-time payments
|
|
- Well-documented APIs for both frameworks
|
|
|
|
### Healthcare Compliance
|
|
**Decision**: PDPA 2010 + additional safeguards
|
|
**Rationale**:
|
|
- Malaysian Personal Data Protection Act compliance
|
|
- Audit trails for patient data access
|
|
- Data encryption at rest and in transit
|
|
- Role-based access control for healthcare data
|
|
- Ready for future international standards adoption
|
|
|
|
### Performance & Scalability
|
|
**Decision**: Vertical scaling first, with horizontal expansion path
|
|
**Rationale**:
|
|
- 100 tenants with 10 users each fits well on single server
|
|
- PostgreSQL connection pooling for efficiency
|
|
- Redis for caching and session management
|
|
- Kubernetes-ready for future expansion
|
|
- Container orchestration for consistent deployment
|
|
|
|
### Infrastructure
|
|
**Decision**: Docker + Kubernetes
|
|
**Rationale**:
|
|
- Consistent development and production environments
|
|
- Malaysian cloud provider support (AWS, Azure, Google Cloud)
|
|
- Auto-scaling capabilities
|
|
- Rolling updates without downtime
|
|
- Malaysian data center options
|
|
|
|
### Module Architecture
|
|
**Decision**: Django Apps with Plugin System
|
|
**Rationale**:
|
|
- Each industry module as separate Django app
|
|
- Shared core infrastructure
|
|
- Plugin-based activation based on subscription
|
|
- Independent testing and deployment
|
|
- Malaysian market-specific customizations per module
|
|
|
|
### Data Retention Implementation
|
|
**Decision**: Automated cleanup with configurable periods
|
|
**Rationale**:
|
|
- 90-day retention period configurable per tenant
|
|
- Soft delete with permanent cleanup
|
|
- Audit logging for compliance
|
|
- Tenant-level override capability
|
|
- Malaysian legal compliance
|
|
|
|
### Testing Strategy
|
|
**Decision**: Pyramid testing approach
|
|
**Rationale**:
|
|
- Contract tests for API compatibility
|
|
- Integration tests for multi-tenant isolation
|
|
- Unit tests for business logic
|
|
- End-to-end tests for user flows
|
|
- Performance tests for scalability validation
|
|
|
|
### Monitoring & Observability
|
|
**Decision**: ELK Stack + Prometheus
|
|
**Rationale**:
|
|
- Malaysian developer community support
|
|
- Multi-tenant usage monitoring
|
|
- Performance bottleneck identification
|
|
- Security event logging
|
|
- Malaysian data residency compliance |