Архитектура SaaS - загрязнение данных

Question

Работа со стартапом в индустрии товаров для дома. Модель SaaS - мультитенантная система. Каждая учетная запись уникально идентифицируется, и все клиенты, проекты и другие данные идентифицируются с использованием уникального номера учетной записи. Мы используем инфраструктуру MVC, а запросы используют сеанс учетной записи, когда пользователь входит в систему. Поскольку мы продолжаем расти, я постоянно переосмысливаю то, что сделал, - обеспокоен перекрестным заражением и другими мультитенантными проблемами.

Есть ли у чего-нибудь хорошие ссылки "Best Practices" или я прошел через то, что я сделал на сегодняшний день? Я считаю свою заботу хорошей вещью, так как я знаю о данных, структуре и еще много чего. Я чувствую себя лучше, чем на самом деле не заботиться.

Answer 1

Я также работаю в компании, которая разрабатывает продукт SaaS в течение многих лет.

Ваш образ мышления правильный.

Пока данные логически разделены соответствующим уникальным идентификатором, который принадлежит конкретному пользователю, вы находитесь на правильном пути.

Вы можете отделить данные, создав отдельную базу данных / схему для каждого из ваших клиентов, изолируя их друг от друга.

Если вы действительно обеспокоены тем, что ваши серверы взломаны, вы можете попытаться разделить деликатные данные на нескольких серверах, чтобы у вас не было всех данных в одном месте. Это потребует более сложных процедур обслуживания, при которых необходимо обновлять каждый сервер для каждого обновления системы, даже не говоря о стоимости такой архитектуры.

Вы всегда можете расширить и создать физическое разделение, когда определенные данные могут находиться на другом сервере базы данных, но я думаю, что виртуальное разделение данных в большинстве случаев более чем нормально - если все сделано правильно.