This document describes the architecture and tools that will be used for the new implementation of DineConnect.

Infrastructure

1. Kubernetes

   • Linode (LKE)

2. Gateway/Ingress

   • Linode NodeBalancer & Traefik Proxy

3. Object Storage

   • Linode

     • S3 compatible

     • Able to host the front-end code

Note

• With regards to k8s, we will start using Linode for development and see if the performance is good and affordable in terms of cost. If yes, we will continue the same for production, otherwise we will switch to other alternatives.

Backend Application

1. Golang

   • Gin/Fiber (for APIs), go-json/sonic (for JSON), GORM (for database)

2. Multi-module

   1. Tenant and Authx Service (TAS)

      • Responsible for creation of tenants and users, logins and permission settings.

   2. Business modules - Connect, Wheels, Clique and others

3. Look like a monolith - single repo, single versioning system.

4. Act like a microservice - we should able to build, containerize and scale modules (i.e. services running in k8s) independently of each other.

5. Expect TAS module, all business modules should be tenant agnostic.

   1. These modules should not be configured with database server credentials.

   2. The code should not make any assumption about multi-tenancy, whether data is isolated based on database separation or using PostgreSQL schema.

   3. When a request reaches a particular module, first it should do tenant data discovery to find out where the tenant data has been stored.

      • In simple terms, it means connecting to the secret store (Infisical) and finding out the database connection details of a particular tenant

   4. Once the initial connection with the database is made and schema is selected, the connection object should be cached in-memory temporarily, so that subsequent requests from the same tenant can be quickly processed without doing the data discovery.

6. Stick to standard SQL data types and avoid using PostgreSQL specific types, as much as possible.

   1. Add // non-standard-SQL comment in the code, if you’re using PostgreSQL specific types and commands.

   2. We should be able to switch to MySQL with minimal code changes, if required.

Open-Source Softwares

The following tools and softwares will be deployed in Kubernetes.

1. Infisical

   • Secret management - for storing tenant-wise database details.

   • { host/port, username, password, database type, database name, schema }

2. ValKey / KeyDB

   • Cache management - user sessions and authorization

   • Also, this is a dependency of Infisical. It needs a Redis-compatible KV store.

3. Hatchet

   • For long running tasks that needs to executed in the background.

     • Data importing, report generation, order consolidation and others.

4. RabbitMQ

   • A dependency of Hatchet. We won’t use it directly.

Database

1. Self-managed database using CloudNativePG.

Note

• Since, we don’t have a proper DevOps / SRE team, managing CloudNativePG might become hard at some point. In such cases, we can move to a managed database solution.

• There are managed solutions such as NeonDB and Supabase, which offers lot of features such as easy Point-In-Time-Recovery, Read Replicas and Branching with a click of button. We won’t need them now, but we can keep an eye on this space and experiment with them.