Architecture and Technology

LockMyCal is designed on the proven and highly reliable Elixir / Erlang VM (BEAM) platform and the Phoenix framework, which ensures unrivalled stability, efficient use of system resources and the ability to serve thousands of concurrent users with minimal RAM and CPU consumption.

Component overview

graph TD
    subgraph Frontend["Frontend & Clients"]
        Browser["Browser (LiveView / WebSocket)"]
        Widget["Embedded JS Widget / iFrame"]
    end

    subgraph Core["LockMyCal Core (Elixir/OTP)"]
        Endpoint["Phoenix Endpoint (Plug Pipeline)"]
        Router["Phoenix Router & Auth Hooks"]
        LiveViews["Phoenix LiveView Sessions"]
        PubSub["Phoenix.PubSub (Real-Time Event Bus)"]
        ObanQueue["Oban Background Jobs (PostgreSQL backed)"]
        ETSCache["ETS In-Memory Cache (Admin & Stats)"]
    end

    subgraph Services["Data & Services"]
        DB[("PostgreSQL 17")]
        Mailers["Swoosh Mailers (SMTP / Postmark)"]
        ExternalSync["OAuth & CalDAV Sync Workers"]
    end

    Browser <--> Endpoint
    Widget <--> Endpoint
    Endpoint --> Router
    Router --> LiveViews
    LiveViews --> PubSub
    LiveViews --> DB
    ObanQueue --> DB
    ObanQueue --> Mailers
    ObanQueue --> ExternalSync

Key technologies

1. Elixir & Phoenix LiveView

• Stateless and stateful real time: Phoenix LiveView keeps a lightweight process for every connected client, which eliminates the need for heavy SPA frameworks and sends only minimal binary differences (diffs) over the network.
• Erlang OTP Concurrency: Every calendar synchronization or webhook runs in an isolated process. An error in one external API never brings down the rest of the application.

2. Database & Queues (Ecto, PostgreSQL, Oban)

• PostgreSQL 17: The primary database for transactional safety, accounts, bookings, settings and audit logs.
• Oban: A robust system for background job queues that uses PostgreSQL tables (no Redis is needed!). It ensures reliable email sending with a retry policy, background synchronization and webhook dispatch.
• Erlang Term Storage (ETS): A fast in-memory cache directly in the virtual machine for frequently read data (e.g. statistics and system parameters).

3. Security and encryption

• Encryption of sensitive data (Data at Rest): Access credentials for calendars and video services (OAuth tokens, CalDAV and Exchange passwords, API keys) and the tokens of Slack, Telegram and webhooks are encrypted using symmetric AES-256-GCM encryption with the dedicated key DATA_ENCRYPTION_KEY.
• Key rotation: Separating SECRET_KEY_BASE (for sessions) and DATA_ENCRYPTION_KEY (for the database) enables safe rotation of session keys without invalidating the saved calendar connections.
• Authentication and RBAC: Secure authentication with protection against brute-force attacks, sign-in via Google, GitHub, Microsoft and generic OIDC, an administrator role and a security audit log.

Extension architecture (Core vs. SaaS Boundary)

LockMyCal uses a modular design. The open-source core provides stable interfaces (Behaviours) to which an optional paid add-on layer connects:

• Tymeslot.Features.CheckerBehaviour – Checking the availability of features (e.g. a custom URL, contacts, automation) and optional limits (e.g. the number of connected calendars).
• Tymeslot.Payments.Behaviours.SubscriptionManager – Managing subscriptions and Stripe webhooks.
• Tymeslot.Auth.Behaviours.AccountDeletionHook – Proper cleanup of external subscriptions when an account is deleted.
• Tymeslot.Dashboard.ExtensionSchema – Registering extension panels in the navigation menu.