День 116 :: Почему мы всё ещё не запустили MVP? Или как Alibaba научила нас не торопиться (но всё равно страшно) 🚀💥
Знаете, в стартапах есть два типа людей: те, кто запускает MVP на коленке за неделю, и те, кто хочет построить космический корабль с первого дня. Мы — вторые. И вот почему.
Проблема: мы не умеем делать «плохо»
Представьте, что вы печете торт. Можно купить готовую смесь, замесить за 5 минут и получить съедобный результат. Но нет — я хочу вырастить пшеницу, собрать ваниль с Мадагаскара и взбить масло вручную. Шутка. Но в ней есть доля шутки.
Наша цель на год — запустить доставку в Крыму. Казалось бы, что может быть проще, чем создание функционала для ОДНОЙ БАЗОВОЙ ТРАНЗАКЦИИ:
1. Разместить тестовый товар.
2. Добавить корзину.
3. Позвать курьера.
4. Profit!
Ну а дальше то что? Клиенты скажут - хотим! А у нас вместо сервиса - Потемкинская деревня.
Поэтому мы хотим сразу рабочую систему, которая выдержит сотни тысяч заказов в секунду, как Alibaba. Или круче. Потому что иначе — зачем? Зачем затевать какую-то фигню на полтора заказа в день?
---
Вот вам отрывок из книги «Alibaba и умный бизнес будущего»:
Вывод: если все строить «на коленке», потом будет больно. Очень.
Почему мы не можем просто «запуститься»?
1. Архитектура — это как фундамент небоскрёба.
Можно построить сарай за день, но когда вы решите вырастить его до 100 этажей, он рухнет. Мы выбираем небоскрёб.
2. Масштаб или смерть.
Наш MVP — не «корзина и курьер». Это система, которая должна обрабатывать тысячи транзакций в секунду, иметь отказоустойчивость, кэширование, распределённые сервисы. Иначе — коллапс, как у Alibaba в 2012.
3. Технологии — это не «допилим потом».
Если сегодня написать код без тестов, завтра он превратится в спагетти-монстра, который съест все наши ресурсы.
---
Что мы делаем вместо запуска?
- Строим систему, которая масштабируется горизонтально.
Чтоб завтра можно было добавить серверов — и она не сдохла.
- Пишем тесты. Много тестов.
Да, это долго. Но когда придёт лавина заказов, мы не хотим, чтобы код напоминал карточный домик.
- Учимся на ошибках гигантов.
Alibaba, Amazon, Netflix — все они прошли через ад масштабирования. Мы просто не хотим повторять их ошибки.
---
Когда же запуск?
Скоро. Очень скоро. Но сначала мы должны быть уверены, что когда вы нажмёте «купить», система не скажет: «Ой, всё».
А пока — спасибо за терпение. Помните: мы строим не сарай. Мы строим космодром. 🚀
@achopochom — закулисье создания стартапа🦄
#стартап #MVP #технологии #масштабирование #Alibaba
Знаете, в стартапах есть два типа людей: те, кто запускает MVP на коленке за неделю, и те, кто хочет построить космический корабль с первого дня. Мы — вторые. И вот почему.
Проблема: мы не умеем делать «плохо»
Представьте, что вы печете торт. Можно купить готовую смесь, замесить за 5 минут и получить съедобный результат. Но нет — я хочу вырастить пшеницу, собрать ваниль с Мадагаскара и взбить масло вручную. Шутка. Но в ней есть доля шутки.
Наша цель на год — запустить доставку в Крыму. Казалось бы, что может быть проще, чем создание функционала для ОДНОЙ БАЗОВОЙ ТРАНЗАКЦИИ:
1. Разместить тестовый товар.
2. Добавить корзину.
3. Позвать курьера.
4. Profit!
Ну а дальше то что? Клиенты скажут - хотим! А у нас вместо сервиса - Потемкинская деревня.
Поэтому мы хотим сразу рабочую систему, которая выдержит сотни тысяч заказов в секунду, как Alibaba. Или круче. Потому что иначе — зачем? Зачем затевать какую-то фигню на полтора заказа в день?
---
Вот вам отрывок из книги «Alibaba и умный бизнес будущего»:
В первые несколько лет после начала распродаж лавинообразное нарастание трафика приводило к выходу из строя серверов Alibaba, коллапсу банковских платежных каналов и прекращению работы сетей, принимающих заказы, по всей стране. После 2012 г., когда утроение объема транзакций практически парализовало систему и задержало доставку заказов на несколько недель, Alibaba и ее многочисленные партнеры постоянно работают над повышением пропускной способности и эффективности логистической системы.
...
Близилась полночь, пальцы пользователей по всей стране, как, впрочем, и по всему миру, застыли в ожидании над экранами смартфонов — в Китае заказы в основном делаются через мобильные устройства. Громкость музыки в центре управления усилилась, когда начался обратный отсчет — пять, четыре, три, два, один.
Чудо происходило у меня на глазах. За 11 секунд объем продаж через нашу платформу достиг 100 млн юаней ($15 млн); 17 секунд спустя — 1 млрд ($150 млн). При этом 97% заказов поступило с мобильных устройств. Лучшие предложения шли нарасхват. Те, кто медлил с оформлением заказа хотя бы несколько секунд, обнаруживали, что продукты, выбранные ими за последний месяц, уже проданы.
Через три минуты объем продаж составлял уже 10 млрд юаней ($1,5 млрд). Потребовался всего час, чтобы достичь совокупного объема продаж за День холостяка в 2014 г., а впереди было целых 23 часа. На пике активности платформы Alibaba обрабатывали 325 000 заказов и 256 000 платежей каждую секунду.
Вывод: если все строить «на коленке», потом будет больно. Очень.
Почему мы не можем просто «запуститься»?
1. Архитектура — это как фундамент небоскрёба.
Можно построить сарай за день, но когда вы решите вырастить его до 100 этажей, он рухнет. Мы выбираем небоскрёб.
2. Масштаб или смерть.
Наш MVP — не «корзина и курьер». Это система, которая должна обрабатывать тысячи транзакций в секунду, иметь отказоустойчивость, кэширование, распределённые сервисы. Иначе — коллапс, как у Alibaba в 2012.
3. Технологии — это не «допилим потом».
Если сегодня написать код без тестов, завтра он превратится в спагетти-монстра, который съест все наши ресурсы.
---
Что мы делаем вместо запуска?
- Строим систему, которая масштабируется горизонтально.
Чтоб завтра можно было добавить серверов — и она не сдохла.
- Пишем тесты. Много тестов.
Да, это долго. Но когда придёт лавина заказов, мы не хотим, чтобы код напоминал карточный домик.
- Учимся на ошибках гигантов.
Alibaba, Amazon, Netflix — все они прошли через ад масштабирования. Мы просто не хотим повторять их ошибки.
---
Когда же запуск?
Скоро. Очень скоро. Но сначала мы должны быть уверены, что когда вы нажмёте «купить», система не скажет: «Ой, всё».
А пока — спасибо за терпение. Помните: мы строим не сарай. Мы строим космодром. 🚀
@achopochom — закулисье создания стартапа🦄
#стартап #MVP #технологии #масштабирование #Alibaba
День 123 :: RabbitMQ или Как очереди спасают микросервисы от апокалипсиса 🐇💥
Представьте: вы открываете кофейню, ставите 10 бариста и кричите: «Кто первый успел — тот и готовит!».
Хаос? Именно так работают микросервисы БЕЗ RabbitMQ.
А теперь — почему мы не запускаемся без него.
Раньше наши сервисы общались напрямую: «Эй, payment-service, обработай платёж!». Если он занят — ошибка.
Теперь всё иначе:
- Запросы падают в очередь и ждут, пока сервис освободится.
- Асинхронность — можно отправить 1000 задач, и они выполнятся когда-нибудь (но точно выполнятся).
- Retry-логика — если сервис упал, RabbitMQ попробует ещё раз. И ещё. И ещё.
Наш MVP должен обрабатывать заказы, даже если inventory-service грузится 5 секунд. Сохранять регистрации, даже если auth-service временно мёртв. Отправлять уведомления, даже если notification-service ушёл на обед.
Без RabbitMQ это выглядит так:
С RabbitMQ:
Очереди важно протестировать со всех сторон, настроить Exchange, Queues, Routing Keys — чтобы задачи не терялись. Важна персистентность — сохранение сообщений на диске, даже если сервер упал.
Ну и мониторинг — следим, чтобы не было лишней нагрузки.
Почему мы не можем «допилить потом»?
1. Без очередей — нет масштаба
- 1000 заказов в секунду убьют сервисы, если они не умеют ждать.
- Отказоустойчивость — если payment-service падает, заказы не пропадают, а ждут в очереди.
2. Реальные примеры апокалипсиса
- Uber: В 2014 их монолит падал при скачках спроса. Перешли на микросервисы + очереди — выжили.
- Netflix: Без RabbitMQ их 150+ млн пользователей остались бы без сериалов.
Когда наш MVP вырастет до уровня Amazon, RabbitMQ позволит:
- Дробить задачи между сотнями воркеров.
- Балансировать нагрузку в реальном времени.
- Сохранять данные, даже если половина серверов горит.
Это ещё одна технология из-за которой мы тормозим. Но только потому, что мы строим систему, которая не сломается при первом же наплыве пользователей.
Важно научить микросервисы работать в команде, а не драться за ресурсы.
Ну и конечно мы готовимся к тому дню, когда наш MVP получит 500 000 заказов за час.
@achopochom — закулисье создания стартапа🦄
#стартап #RabbitMQ #очереди #масштабирование #микросервисы
Представьте: вы открываете кофейню, ставите 10 бариста и кричите: «Кто первый успел — тот и готовит!».
Хаос? Именно так работают микросервисы БЕЗ RabbitMQ.
А теперь — почему мы не запускаемся без него.
Раньше наши сервисы общались напрямую: «Эй, payment-service, обработай платёж!». Если он занят — ошибка.
Теперь всё иначе:
- Запросы падают в очередь и ждут, пока сервис освободится.
- Асинхронность — можно отправить 1000 задач, и они выполнятся когда-нибудь (но точно выполнятся).
- Retry-логика — если сервис упал, RabbitMQ попробует ещё раз. И ещё. И ещё.
Наш MVP должен обрабатывать заказы, даже если inventory-service грузится 5 секунд. Сохранять регистрации, даже если auth-service временно мёртв. Отправлять уведомления, даже если notification-service ушёл на обед.
Без RabbitMQ это выглядит так:
Пользователь → "Оплатил заказ!" → Сервис упал → "Где мой заказ?!" → 1 звезда в рейтинге. С RabbitMQ:
Пользователь → "Оплатил заказ!" → Задача в очереди → Сервис ожил → Всё ок. Очереди важно протестировать со всех сторон, настроить Exchange, Queues, Routing Keys — чтобы задачи не терялись. Важна персистентность — сохранение сообщений на диске, даже если сервер упал.
Ну и мониторинг — следим, чтобы не было лишней нагрузки.
Почему мы не можем «допилить потом»?
1. Без очередей — нет масштаба
- 1000 заказов в секунду убьют сервисы, если они не умеют ждать.
- Отказоустойчивость — если payment-service падает, заказы не пропадают, а ждут в очереди.
2. Реальные примеры апокалипсиса
- Uber: В 2014 их монолит падал при скачках спроса. Перешли на микросервисы + очереди — выжили.
- Netflix: Без RabbitMQ их 150+ млн пользователей остались бы без сериалов.
Когда наш MVP вырастет до уровня Amazon, RabbitMQ позволит:
- Дробить задачи между сотнями воркеров.
- Балансировать нагрузку в реальном времени.
- Сохранять данные, даже если половина серверов горит.
Это ещё одна технология из-за которой мы тормозим. Но только потому, что мы строим систему, которая не сломается при первом же наплыве пользователей.
Важно научить микросервисы работать в команде, а не драться за ресурсы.
Ну и конечно мы готовимся к тому дню, когда наш MVP получит 500 000 заказов за час.
@achopochom — закулисье создания стартапа🦄
#стартап #RabbitMQ #очереди #масштабирование #микросервисы