System Architecture
This document provides a comprehensive overview of the Effective Office system architecture, covering the overall design patterns, major components, and their interactions. It focuses on the technical structure of both backend services and client applications, their integration patterns, and deployment architecture.
For specific implementation details about individual features, see Core Features. For deployment procedures and operational aspects, see Deployment & Operations.
The Effective Office system follows a client-server architecture designed for office resource management and ambient communications. A Spring Boot backend exposes REST APIs that power Compose Multiplatform tablet clients (booking), an Android TV signage client, and Android-based SMS router devices. Each client consumes the same domain models and messaging pipelines while targeting a dedicated user journey.
The backend follows a modular Spring Boot architecture with clear separation between core infrastructure and business features. Each module has specific responsibilities and well-defined interfaces.
The system centers around key domain entities that represent the business logic:
| Entity | Purpose | Key Attributes |
|---|---|---|
Booking |
Represents workspace reservations |
id, owner, participants, workspace, beginBooking, endBooking, recurrence
|
User |
System users and organizers |
id, username, email, firstName, lastName, role
|
Workspace |
Bookable rooms and spaces |
id, name, utilities, zone, tag
|
EventInfo |
Client-side event representation |
startTime, finishTime, organizer, isEditable
|
The tablet client uses Compose Multiplatform with a modular, feature-based architecture. It implements the MVI pattern with Decompose for navigation and state management.
The Android TV application focuses on autoplay playlists, Notion/Duolingo/Leader ID data pipelines, and remote-control friendly UI built with Jetpack Compose for TV, Hilt, Retrofit, Coil, and ZXing for QR generation. Its Story Engine consumes the same backend APIs for configuration while maintaining independent scheduling logic.
The SMS router Android app intercepts inbound SMS via system broadcasts, persists per-SIM settings, and forwards messages to Mattermost/Telegram webhooks through a Ktor HTTP client. Compose Material 3 screens expose diagnostics, while Room stores delivery logs for later auditing.
The system uses modern Kotlin-based technologies throughout the stack:
| Component | Technology | Version |
|---|---|---|
| Framework | Spring Boot | 3.5.0 |
| Language | Kotlin | 2.1.21 |
| Database | PostgreSQL | 42.7.6 |
| Security | JWT | 0.11.5 |
| Documentation | SpringDoc OpenAPI | 2.8.8 |
| External API | Google Calendar API | 1.33.0 |
| Build Tool | Gradle | 8.x |
| Client | Stack Highlights |
|---|---|
| Tablet | Compose Multiplatform 1.8.1, Decompose 3.3.0, Koin 4.1.0, Essenty 2.5.0, Ktor 3.1.3, Kotlinx.datetime 0.6.2 |
| TV | Jetpack Compose for TV, Hilt, Retrofit + OkHttp, Coil (SVG/AVIF), ZXing, Kotlin Coroutines/Flow |
| SMS Router | Android Compose Material 3, Koin, Ktor HTTP client, Room, Napier/SLF4J logging, Kotlinx.serialization |
The system implements several key data flow patterns for real-time updates and calendar synchronization.
The system uses consistent data transformation patterns between domain models and DTOs:
The system uses containerized deployment with Docker Compose for orchestration and Caddy as a reverse proxy.
The system architecture emphasizes modularity, testability, and maintainability through clear separation of concerns, well-defined interfaces between components, and consistent patterns for data flow and external integrations.