Здравствуйте.
Да, я знаю, что никогда не стоит заниматься преждевременной оптимизацией, но и монолит писать тоже не стоит.
Имеется задача:
Написание приложения вроде UBER. Только веб-версия. Ожидаемый онлайн - около 800 000 человек в каждый момент будут постоянно в сети, передвигаться, и, следовательно, обмениваться данными.
Планирую использовать:
DJANGO.
Для Realtime-шаринга геоданными - Node.JS + SOCKET.IO.
Основное хранилище: Postgres.
Хранилище для меток (кафе и пр.): SQLlite.
Node.JS-часть: горизонтально масштабируемая, новые сервера автоматически входят в эксплуатацию, вышедшие из строя из эксплуатации выводятся. Каждый сервер хранит в себе кэш с онлайн пользователями. Сервера взаимодействуют между собой.
Вопрос по DJANGO: какую архитектуру лучше выбрать? Желательно с примерами. Условие: горизонтальная масштабируемость, работа с общей РСУБД.
Так же любые предложения для улучшения архитектуры, облегчения оптимизации и пр. в будущем вкупе с конструктивной критикой приветствуются.
Заранее всем спасибо. Ранее с HL не работал, поэтому, по возможности, прошу помочь и примерами. Уж извините. :)
sim3x, планируется 30К rps в первое время (если я про тот же термин).
Realtime обмен геоданными - основная идея сервиса, его изюминка, если так можно выразиться
Sergey Grigorov,
Стоит оговориться, что на такой проект стоит нанять CTO, который будет иметь опыт разработки на такого рода проектах в указанных стеках
Без толкового офицера у вас не получится выйти на 30к rps с запасом
>Условие: горизонтальная масштабируемость, работа с общей РСУБД.
изначально противоречивые условия.
---
не стоит вам на ноде воротить что-либо для управления серверами и на ее основе выстраивать микросервесную архитектуру.
Посмотрите Kafka, Cassandra.
Средний
