Legacy Metro Retro Help
  • Metro Retro v3 - Help Guide
  • Metro Retro v2 - Help Guide
  • Introduction
    • Get Started with Metro Retro
  • Boards
    • Create a board
    • Design Mode & Meeting Mode
    • Share your board
    • How to hide and reveal sticky notes
    • How to set the timer
    • The Toolbar
    • Host controls
    • Customizing the board layout
    • Locking the layout
    • Collaboration tips
    • Import data to your boards
    • Export your board
    • Beta Features
  • Dashboard
    • Dashboard Overview
    • Workspaces
    • Template Library
  • Management
    • Admins
    • Security, Logins, SSO
      • Single Sign-On
        • Azure Integration
        • Google Integration
        • Okta Integration
    • Invite and Access Approvals
    • Manage People
    • Manage Workspaces
    • Billing & Subscription
      • Trials
  • Plans (Legacy)
    • Plans Overview (legacy)
      • Pro Plan (Legacy)
      • Business Plan (Legacy)
      • Enterprise Plan
  • Roadmap
    • Differences between v1 and v2
    • Release Notes
    • Roadmap
  • Technical
    • Technical Overview
  • Help
    • FAQs
      • General FAQS
      • "How-To" FAQs
      • Using Metro Retro FAQs
      • Pricing FAQs
Powered by GitBook
On this page
  • Introduction
  • Logical Topology
  • Physical Topology
  • Cloud Deployment
Export as PDF
  1. Technical

Technical Overview

This page gives a brief overview of the Metro Retro architecture and system requirements.

PreviousRoadmapNextFAQs

Last updated 2 years ago

Introduction

Metro Retro is a dynamic, real-time application providing users with a rich interactive environment to work collaboratively. It is primarily deployed into a virtual private cloud operated by Deqo Software Ltd and provided in the form of Software as a Service.

This article describes the architecture of Metro Retro. See our and pages for more information on our security and data protection practices.

Logical Topology

Metro Retro is exposed to customers as a . Behind this, there are a number of services working in synergy to provide a working service. From a logical perspective (ignoring hardware), these are:

Service
Product / Provider
Role

Web Gateway

Caddy

Acts as reverse proxy and load balancer.

Content Delivery Network

BunnyCDN

Provides edge cache for static assets & SPA build files.

App Server

NodeJS Application

Application API (HTTP based) and Auth/Login UI.

Podopolis

Elixir Application

Socket server that enables the real time collaboration functionality.

Main Database

Postgres

Stores all system data except for board contents.

Object Database

MongoDB

Stores board contents.

Cache

Redis

Provides a cache and short term storage solution.

Message Queue

Rabbit MQ

Enables inter-service communication between components.

File Store

S3 Compatible Storage

Stores static assets & user uploaded data.

App Worker

NodeJS Application

Background job processor for various system tasks/functionality.

Snapper

NodeJS Application

Generates board preview images via Puppeteer.

The diagram below shows the logical topology layout including the data transfer routes. Blue lines are one way transfers, purple lines are bi-directional transfers.

Physical Topology

Cloud Deployment

Within the main cloud deployment, we utilize Digital Ocean with the following:

  • Ubuntu VMs for App Server, App Worker, Snapper, Podopolis, Rabbit MQ, Redis & Caddy

  • Digital Ocean Managed Postgres & MongoDB instances

  • Digital Ocean Spaces (S3 Compatible Storage)

  • Bunny CDN as the external CDN provider

Each component runs directly on a dedicated VM of a size applicable for the current system load.

Security
Privacy Policy
single page web application