Architecture Overview
Comprehensive overview of the Xikolo platform architecture, including high-level system design, component organization, design patterns, and architectural decisions.
High-Level Architecture
System Components Overview
Rails + TypeScript] MOBILE[Mobile Apps
iOS / Android] end subgraph "API Gateway" GATEWAY[API Gateway
Request Routing] end subgraph "Microservices" COURSE[Course Service] ACCOUNT[Account Service] QUIZ[Quiz Service] VIDEO[Video Service] CERTIFICATE[Certificate Service] end subgraph "Infrastructure" DB[(PostgreSQL
Database)] REDIS[(Redis
Cache)] S3[S3 Storage
Assets/Videos] JOBS[Background Jobs
Sidekiq] end WEB --> GATEWAY MOBILE --> GATEWAY GATEWAY --> COURSE GATEWAY --> ACCOUNT GATEWAY --> QUIZ GATEWAY --> VIDEO GATEWAY --> CERTIFICATE COURSE --> DB ACCOUNT --> DB QUIZ --> DB VIDEO --> S3 CERTIFICATE --> S3 WEB --> REDIS JOBS --> REDIS style WEB fill:#667eea,stroke:#764ba2,stroke-width:2px,color:#fff style GATEWAY fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff style COURSE fill:#2ecc71,stroke:#27ae60,stroke-width:2px,color:#fff
Architecture Layers
Presentation Layer
- Rails Views & Controllers
- TypeScript Frontend
- Mobile Applications
- UI Components
- Responsive Design
Business Logic Layer
- Service Objects
- Domain Models
- Business Rules
- Presenters
- Form Objects
Data Layer
- PostgreSQL Database
- ActiveRecord Models
- Migrations
- Data Validation
- Associations
Layer Communication Flow
Design Patterns
Service Objects
Purpose: Encapsulate complex business logic separate from models and controllers.
Usage: User enrollment, course completion, certificate generation.
Benefits: Testable, reusable, single responsibility.
Presenter Pattern
Purpose: Separate view logic from models and controllers.
Usage: Course display, user profiles, quiz results.
Benefits: Clean views, testable presentation logic.
Repository Pattern
Purpose: Abstract data access layer for flexibility.
Usage: Microservice communication via ACFS.
Benefits: Decoupled data access, easy testing.
Form Objects
Purpose: Handle complex form validation and processing.
Usage: Multi-step forms, nested attributes.
Benefits: Clean controllers, reusable validation.
Background Jobs
Purpose: Asynchronous task processing.
Usage: Email sending, video processing, report generation.
Benefits: Non-blocking, scalable, resilient.
Decorator Pattern
Purpose: Extend object functionality dynamically.
Usage: Authorization, caching, logging.
Benefits: Flexible, composable, maintainable.
Microservices Architecture
Microservices Interaction
Key Architectural Decisions
✅ Ruby on Rails Framework
Decision: Use Rails as the primary web framework.
Rationale: Rapid development, convention over configuration, mature ecosystem.
Trade-offs: Monolithic tendencies, learning curve for new developers.
✅ Microservices via ACFS
Decision: Separate concerns into domain-specific microservices.
Rationale: Scalability, independent deployment, team autonomy.
Trade-offs: Increased complexity, network latency, distributed debugging.
✅ PostgreSQL Database
Decision: PostgreSQL as the primary relational database.
Rationale: ACID compliance, advanced features, JSON support, reliability.
Trade-offs: Vertical scaling limitations, operational complexity.
✅ Redis for Caching
Decision: Redis for caching and session storage.
Rationale: High performance, simple API, pub/sub support.
Trade-offs: Memory constraints, persistence configuration needed.
✅ TypeScript Frontend
Decision: Migrate JavaScript to TypeScript.
Rationale: Type safety, better IDE support, fewer runtime errors.
Trade-offs: Build complexity, migration effort, learning curve.
✅ Sidekiq for Jobs
Decision: Sidekiq for background job processing.
Rationale: Redis-backed, performant, great Rails integration.
Trade-offs: Redis dependency, job retry complexity.