В идеале это вообще должны быть отдельные сервисы с отдельными базами. А данные между ними должны разделяться через какой-то API (например HTTP).
Примерно вот как будет выглядеть взаимодействие этих сервисов:
- Кто то владелец общих данных, например сервис на Django (D)
- Когда сервису на Tornado (T) понадобились данные, он сходил по http в D, получил данные и продолжил обрабатывать запрос (при этом T сходил к D асинхронно)
- Когда сервису T надо обновить данные в D он просто дернул за API (отправил POST/PUT) D.
Преимущества этого решения:
- Вы разделяете кодовую базу. Ее становится проще тестировать.
- Вам больше не надо синхронизировать миграции, теперь вам нужна просто клиентская библиотека для другого сервиса.
Минусы:
- Необходимо перерабатывать сервисы
- На то, чтобы сходить по HTTP за данными понадобиться больше времени, чем на то, чтобы сходить в базу.
Резюмируя:
Разделение на сервисы сейчас тренд и сейчас есть много статей в которых более детально описаны минусы и плюсы.