Текст выглядит так, будто LLM модель помогла собрать убедительную форму вокруг изначально ошибочной связки тезисов. Но LLM не заменяет понимание предметной области и техническое ревью. Если плохо разложить задачу на уровни, на выходе получается гладкий, но методологически слабый материал.
Читатель получает не аккуратный разбор архитектуры multi-tenant SaaS, а драматизированное описание базового бага, искусственно связанное с темами, к которым он почти не относится. Мне кажется, перед следующими материалами стоит глубже разобрать тему и отдельно проверить техническую логику текста, а не только его подачу.
После вашего уточнения становится понятно, что проблема была не в config.TENANT_ID, а в том, что в проекте одновременно жили две разные модели tenancy.
Часть системы уже была shared multi-tenant: таблицы с tenant_id, выборки через user.tenant_id, разные клиники в одной схеме. А часть write-path продолжала работать как single-tenant-приложение через глобальный config.TENANT_ID.
Но тогда не очень понятно, как именно эта ошибка связывает между собой разные архитектуры разделения данных: shared DB + tenant_id, schema-per-tenant, database-per-tenant и так далее. Баг был не в выбранной модели хранения данных, а в том, что приложение неконсистентно определяло текущего tenant’а. Это уровень runtime-контекста запроса, а не доказательство за или против конкретной схемы изоляции данных.
Это не «самая дорогая ошибка SaaS». Это базовый баг, который должен ловиться первым же E2E-тестом на двух tenant’ов.
Если система реально multi-tenant, минимальная проверка выглядит элементарно: tenant B создаёт врача — tenant B его видит, tenant A его не видит. Если запись уехала в tenant-1, тест сразу красный.
Поэтому статья драматизирует не ту проблему. config.TENANT_ID сам по себе не плохой и не хороший. Он нормален в архитектуре «один tenant — один instance» и ошибочен в shared multi-tenant runtime.
Настоящий вывод должен быть не «не используйте config.TENANT_ID», а «не смешивайте tenancy-модели, явно определяйте источник tenant context и покрывайте изоляцию tenant’ов базовыми тестами».
Логичнее было бы сфокусироваться на маркетинговых статьях, где у вас уже возможно есть сильная экспертиза, и осторожнее подходить к техническим темам. Возможно, когда LLM-модели станут лучше вы сможете вернуться к техническим статьям.
config.TENANT_ID - это не обязательно техдолг. Это может быть нормальное архитектурное решение, если система построена по модели «один instance приложения — один tenant».
Например у нас два адреса: tenant1.example.com, tenant2.example.com При этом каждый поддомен может вести на отдельный instance приложения или отдельный контейнер, где TENANT_ID задан через конфиг или переменные окружения. В этом случае приложение само не «вычисляет» tenant из запроса, а берет из настроек (config.TENANT_ID) окружения приложения.
Посмотрите как работает django.contrib.sites
Другой подход - один общий instance приложения для многих tenants. При данном подходе вы динамически фильтруете tenant в рамках одного instance приложения.
Посмотрите как работает django-tenants
Поэтому нельзя называть захардкоженный config.TENANT_ID техдолгом. Это может быть плохим решением в одной архитектуре и совершенно нормальным решением в другой.
Перед публикацией таких материалов я бы рекомендовал отдавать их на техническое ревью нескольким LLM моделям, потому что сейчас выводы выглядят так, будто вы смешали все в одну кучу.
Текст выглядит так, будто LLM модель помогла собрать убедительную форму вокруг изначально ошибочной связки тезисов. Но LLM не заменяет понимание предметной области и техническое ревью. Если плохо разложить задачу на уровни, на выходе получается гладкий, но методологически слабый материал.
Читатель получает не аккуратный разбор архитектуры multi-tenant SaaS, а драматизированное описание базового бага, искусственно связанное с темами, к которым он почти не относится. Мне кажется, перед следующими материалами стоит глубже разобрать тему и отдельно проверить техническую логику текста, а не только его подачу.
После вашего уточнения становится понятно, что проблема была не в
config.TENANT_ID, а в том, что в проекте одновременно жили две разные модели tenancy.Часть системы уже была shared multi-tenant: таблицы с
tenant_id, выборки черезuser.tenant_id, разные клиники в одной схеме. А часть write-path продолжала работать как single-tenant-приложение через глобальныйconfig.TENANT_ID.Но тогда не очень понятно, как именно эта ошибка связывает между собой разные архитектуры разделения данных:
shared DB + tenant_id,schema-per-tenant,database-per-tenantи так далее. Баг был не в выбранной модели хранения данных, а в том, что приложение неконсистентно определяло текущего tenant’а. Это уровень runtime-контекста запроса, а не доказательство за или против конкретной схемы изоляции данных.Это не «самая дорогая ошибка SaaS». Это базовый баг, который должен ловиться первым же E2E-тестом на двух tenant’ов.
Если система реально multi-tenant, минимальная проверка выглядит элементарно: tenant B создаёт врача — tenant B его видит, tenant A его не видит. Если запись уехала в
tenant-1, тест сразу красный.Поэтому статья драматизирует не ту проблему.
config.TENANT_IDсам по себе не плохой и не хороший. Он нормален в архитектуре «один tenant — один instance» и ошибочен в shared multi-tenant runtime.Настоящий вывод должен быть не «не используйте config.TENANT_ID», а «не смешивайте tenancy-модели, явно определяйте источник tenant context и покрывайте изоляцию tenant’ов базовыми тестами».
Логичнее было бы сфокусироваться на маркетинговых статьях, где у вас уже возможно есть сильная экспертиза, и осторожнее подходить к техническим темам.
Возможно, когда LLM-модели станут лучше вы сможете вернуться к техническим статьям.
config.TENANT_ID - это не обязательно техдолг. Это может быть нормальное архитектурное решение, если система построена по модели «один instance приложения — один tenant».
Например у нас два адреса: tenant1.example.com, tenant2.example.com
При этом каждый поддомен может вести на отдельный instance приложения или отдельный контейнер, где TENANT_ID задан через конфиг или переменные окружения. В этом случае приложение само не «вычисляет» tenant из запроса, а берет из настроек (config.TENANT_ID) окружения приложения.
Посмотрите как работает django.contrib.sites
Другой подход - один общий instance приложения для многих tenants. При данном подходе вы динамически фильтруете tenant в рамках одного instance приложения.
Посмотрите как работает django-tenants
Поэтому нельзя называть захардкоженный config.TENANT_ID техдолгом. Это может быть плохим решением в одной архитектуре и совершенно нормальным решением в другой.
Перед публикацией таких материалов я бы рекомендовал отдавать их на техническое ревью нескольким LLM моделям, потому что сейчас выводы выглядят так, будто вы смешали все в одну кучу.
www.indiegogo.com/projects/solar-roadways
www.solaroad.nl/en/hoe-is-het-idee-ontstaan/ пишут, что идея была презентована в 2009 году на местном голландском форуме.