multitenetsaas/specs/001-1-target-sectors/research.md

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