Skip to main content

System Architecture

Mirobody Health is built with a modular, layered architecture that separates concerns and enables easy extensibility.

Core Components

API Layer

FastAPI-based REST API for external integrations

Provider System

Pluggable OAuth integrations for health devices

Data Pipeline

ETL pipeline for health data transformation

AI Services

Multi-provider LLM integration for chat

MCP Protocol

Model Context Protocol for AI agents

Storage Layer

PostgreSQL and Redis for data persistence

Architecture Layers

1. API Layer

The API layer provides RESTful endpoints for all system interactions:
HTTP Server (FastAPI)
├── /api/v1/pulse/          # Health provider endpoints
├── /api/chat               # AI chat interface
├── /api/history            # Session history
└── /mcp                    # MCP protocol endpoint
Key Features:
  • Async request handling with FastAPI
  • Automatic API documentation (OpenAPI/Swagger)
  • CORS support for web clients
  • Request validation with Pydantic models
  • JWT-based authentication

2. Provider System

Pluggable architecture for health device integrations: Components:
  • BaseThetaProvider: Abstract base class for all providers
  • ThetaDataFormatter: Standard data transformation utilities
  • ThetaTimeUtils: Timezone and timestamp handling
  • Provider-specific implementations (Garmin, Whoop, etc.)

3. Data Pipeline (TBD)

ETL (Extract, Transform, Load) pipeline for health data:
┌─────────────┐
│  Pull Data  │ ─┐
└─────────────┘  │

┌─────────────┐  │  ┌──────────────┐
│  Save Raw   │ ◄┴─▶│ Push Service │
└─────────────┘     └──────────────┘
        │                   │
        ▼                   ▼
┌─────────────┐    ┌──────────────┐
│  Format     │    │  Upload      │
└─────────────┘    └──────────────┘
        │                   │
        ▼                   ▼
┌─────────────┐    ┌──────────────┐
│ Standardize │    │  Platform    │
└─────────────┘    └──────────────┘
Flow:
  1. Pull: Fetch data from vendor API
  2. Save: Store raw data in database
  3. Format: Transform to standard format
  4. Upload: Push to Mirobody platform

4. AI Services

Multi-provider LLM integration for intelligent health insights:
AI Services
├── OpenRouter (Multi-model)
├── OpenAI (coming later)
├── Google (coming later)
├── Anthropic (coming later)
└── Local LLMs (coming later)
Features:
  • Provider-agnostic interface (coming later)
  • Context management for conversations
  • Tool calling for health data access
  • Session history persistence

5. MCP Protocol

Model Context Protocol support for AI agent integration:
MCP Server
├── Tools/        # Available tools
│   ├── get_user_health_profile
│   ├── get_health_indicator
│   └── your custom tools
├── Resources/    # Available resources
Capabilities:
  • JSON-RPC 2.0 interface
  • Tool discovery and execution
  • Resource management
  • Agent orchestration

6. Storage Layer

Dual storage system for different data types:
Used for:
  • User credentials (encrypted)
  • OAuth tokens and refresh tokens
  • Raw health data (JSONB)
  • Provider configurations
  • Session history

Data Flow

OAuth Authentication Flow

Health Data Synchronization

Design Patterns

Plugin Architecture

Providers are discovered and loaded dynamically:
# Provider discovery
THETA_PROVIDER_DIRS = ["connect/theta"]

# Automatic loading
for directory in THETA_PROVIDER_DIRS:
    providers = discover_providers(directory)
    for provider_class in providers:
        provider = provider_class.create_provider(config)
        if provider:
            register_provider(provider)

Factory Pattern

Providers use factory methods for conditional instantiation:
@classmethod
def create_provider(cls, config: Dict) -> Optional['Provider']:
    """Factory method - returns None if config invalid"""
    if not cls._validate_config(config):
        return None
    return cls()

Strategy Pattern

Different OAuth strategies for OAuth 1.0 vs 2.0:
class BaseThetaProvider:
    def link(self, request) -> Dict:
        """Implemented by OAuth1 or OAuth2 strategy"""
        pass
    
    def callback(self, *args, **kwargs) -> Dict:
        """Implemented by OAuth1 or OAuth2 strategy"""
        pass

Repository Pattern

Database operations abstracted through services:
class DatabaseService:
    async def save_oauth2_credentials(self, ...): pass
    async def get_user_credentials(self, ...): pass
    async def delete_user_theta_provider(self, ...): pass

Security Architecture

  • JWT-based API authentication
  • OAuth 1.0/2.0 for provider access
  • Encrypted credential storage
  • Per-user provider access control
  • Database-level encryption
  • Encrypted OAuth tokens
  • HTTPS for all external communication
  • Sensitive data never logged
  • User-scoped data access
  • Provider-specific permissions
  • API rate limiting
  • CORS policies
  • TLS/SSL for external APIs
  • State parameter for OAuth CSRF protection
  • Token refresh mechanisms
  • Secure session management

Scalability Considerations

Horizontal Scaling

The system supports horizontal scaling:

Stateless API

API servers are stateless, enabling horizontal scaling behind a load balancer

Distributed Cache

Redis supports clustering for distributed caching

Database Pooling

Connection pooling enables multiple API instances

Async Processing

Async/await enables high concurrency per instance

Deployment Architecture

Docker Compose Architecture

services:
  backend:
    image: mirobody-backend
    ports: ["18080:18080"]
    depends_on: [db, redis]
    
  db:
    image: postgres:15
    volumes: ["pgdata:/var/lib/postgresql/data"]
    
  redis:
    image: redis:7
    volumes: ["redis-data:/data"]

volumes:
  pgdata:
  redis-data:

Monitoring & Observability

Logging

Structured logging throughout the system:
# Log levels
LOG_LEVEL: INFO  # DEBUG, INFO, WARNING, ERROR, CRITICAL

# Contextual logging
logging.info(
    "Data pull completed",
    extra={
        "user_id": user_id,
        "provider": provider_slug,
        "records": len(data),
        "duration_ms": duration
    }
)

Metrics

Track key performance indicators:
  • Request latency
  • Provider success rates
  • Data processing throughput
  • Error rates by provider
  • Token refresh rates

Health Checks

GET /health
{
  "status": "healthy",
  "version": "1.0.1",
  "services": {
    "database": "connected",
    "redis": "connected"
  }
}

Technology Stack

  • Python 3.12+: Core language
  • FastAPI: Web framework
  • asyncio: Async I/O
  • Pydantic: Data validation
  • SQLAlchemy: Database ORM

Extensibility Points

The architecture provides multiple extension points:
See Development new health device integrations:
  1. See Adding Custom Tools to add new tools for AI agents
  2. See Adding Custom MCPs to add new MCPs for AI agents
Add new health metrics:
  1. Define in StandardIndicator enum
  2. Specify standard unit
  3. Update provider mappings
Add new LLM providers:
  1. Implement provider interface
  2. Add configuration
  3. Register in agent system
  4. Deploy

Best Practices

Separation of Concerns

Each layer has a single responsibility

Dependency Injection

Services injected, not hard-coded

Interface-Based Design

Program to interfaces, not implementations

Configuration-Driven

Behavior controlled via configuration

Async First

Async/await for all I/O operations

Error Handling

Graceful degradation and recovery

Next Steps