From 5e05baef6c593663719c19a0c71adb79785c1e6d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerg=C5=91=20Jedlicska?=
 <57442769+gjedlicska@users.noreply.github.com>
Date: Mon, 12 Feb 2024 13:19:23 +0100
Subject: [PATCH] Delete assignment.md

---
 assignment.md | 14 --------------
 1 file changed, 14 deletions(-)
 delete mode 100644 assignment.md

diff --git a/assignment.md b/assignment.md
deleted file mode 100644
index ed0427d..0000000
--- a/assignment.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# Technical assignment
-
-The multi tenant application found in this repository is a striped down but functional example of what we need from our production system.
-The current state of this application has some shortcomings, that stops us from choosing this data storage architecture:
-
-- with each organization living in its own database in a specific database server, we need to replicate all user data into each organization specific database.
-  We do not need to sync all users into all organization's dbs, just the users, who are part of a given organization
-- each organization has to publish their resource data into the main database and the main database has to subscribe to them.
-  In the long run the number of active subscriptions in the main database scales 1:1 with the number of organizations, which is not ideal.
-- Each organization may have access to multiple regions. Each organization's region currently means 1 `knex` database connection client with a connection pool.
-  In a production workload, the connection pool would use 10+ connections. We'd run multiple instances (~ 10 pods) of the back-end server.
-  Given a 100 organizations, having access to 3 regions each, the number of active connections that are targeting each database server becomes huge. This is not scalable.
-- Each organizations database connection's are now kept in an in memory map, that can result storing a lot not used clients in memory.
-  How can we optimize for efficient but relatively fast client access?