The post has been translated automatically. Original language: Russian
Last fall, the Internet reminded us twice in ten days that the "cloud" is actually an ordinary building with servers. First, on October 20, 2025, one AWS region in Northern Virginia failed, and more than a hundred services around the world began to fail at once: delivery, banking, and flight check—in. Less than nine days later, the same thing happened at Microsoft Azure: Teams, Outlook, Xbox, and check-in desks of entire airlines stopped working. The reason in both cases was not hackers or a fire, but one erroneous setup that cascaded everything else down.
The conclusion from this is simple. A single data center is always a single point of failure, even if it is top—notch equipped with backup power and cooling. No uninterruptible power supply can protect you from a configuration error or a malfunction that covers the entire region. Engineers can build exceptionally reliable facilities, but absolute reliability does not exist, and sooner or later it makes itself felt.
Therefore, serious projects do not rely on one site, but distribute the load across several data centers at once. They start by duplicating the equipment within the same hall, then they distribute it to different buildings in the city — these are called accessibility zones — and at the most responsible level they distribute it to different cities and countries so that no local accident can affect both sites at the same time.
The next question is how to link these platforms. The first approach: the main one is working, and the second one is in hot standby and picks up the load if the first one fails. It's cheaper, but switching takes time, and it needs to be worked out regularly. A reserve that has never been tested under load is not a reserve, but just a hope. The second approach: both sites work simultaneously and share traffic, so that the fall of one passes almost unnoticeably. More reliable, but also noticeably more expensive.
And there is another non-obvious point that is usually reached through experience. A reserve that shares a common relationship with the main site is no longer a reserve. This is exactly what many people faced last fall: the servers were located in different regions, but they relied on the same provider's management system — once it failed, geography did not help. It can be simpler: two platforms from one substation or two channels from one operator. On paper, it's a reserve, but in fact it's a common weak point that pulls both together.
In general, geo—distribution is not about reinsurance and not about the number of sites for the sake of solidity, but about a sound calculation: understand how much an hour of downtime costs, and invest in independence exactly as much as it is justified. True fault tolerance is based on two simple things: the sites should not have a common point of failure, and switching between them should be checked in advance, in a calm environment, and not in the midst of an accident.
The good news is that all this is not so much a matter of budget as of thoughtful architecture. And it is quite possible to build it, if you think about it in advance.
And how has this issue been resolved with you — do you keep the project on one site or are you already looking at a backup one?
Почти каждая современная компания собирает персональные данные — даже если не осознаёт этого. Форма заказа, регистрация в приложении, база клиентов в CRM, а иногда достаточно и незаметных вещей: идентификатора устройства или push-токена. При этом вопрос, где эти данные физически хранятся, задают себе единицы. А закон Казахстана относится к нему серьёзно.
Главное правило: локализация
Ключевое требование закона РК «О персональных данных и их защите» (№ 94-V) простое и понятное. Это норма пункта 2 статьи 12: персональные данные хранятся в базе, находящейся на территории Республики Казахстан. Удобный зарубежный хостинг, облако с серверами в Европе или США, привычный внешний сервис — если там лежит база с данными казахстанцев, это уже повод присмотреться внимательнее.
Что вообще считается персональными данными
Здесь кроется неочевидный момент — понятие шире, чем кажется. Это не только паспорт и ИИН. Даже без формы регистрации приложение обычно обрабатывает device ID, push-токены и данные аналитики — этого уже достаточно, чтобы считаться оператором персональных данных. А касается это очень многих: интернет-магазинов, медицинских учреждений, банков, сервисов доставки, образовательных платформ, HR-агентств.
Можно ли передавать данные за границу
Можно, но по правилам. Трансграничная передача допускается при наличии согласия человека и адекватного уровня защиты в стране-получателе. То есть пользоваться внешней аналитикой или зарубежными сервисами не запрещено — но первичная база всё равно остаётся в РК, а передача оформляется осознанно.
Почему это стоит держать в голове
Тема локализации в последние годы на слуху всё заметнее, и внимание к ней со стороны регулятора растёт. Но дело даже не в формальных требованиях. Понимание того, где физически живут данные ваших клиентов, — это признак зрелого продукта и уважения к людям, которые вам доверились. Компании, которые задумываются об этом заранее, просто чувствуют себя увереннее.
С чего начать
Ничего сложного здесь нет — достаточно один раз разобраться. Рабочая и удобная схема, особенно для продуктов с прицелом за пределы РК: основная база — на инфраструктуре в Казахстане, а во внешние сервисы уходит только обезличенная аналитика. Хорошая отправная точка — просто ответить себе на вопрос: где именно, на каком сервере и в какой стране, сейчас лежат данные моих пользователей? Часто уже сам этот вопрос подсказывает, что стоит поправить.
Персональные данные давно стали ценностью — и для бизнеса, и для самих людей. Заложить понимание этого в продукт с самого начала намного проще, чем перестраивать всё потом. А начинается всё с простого вопроса самому себе.
Отмечу: это обзор для размышления, а не юридическая консультация. Требования со временем меняются, и по конкретной ситуации всегда стоит свериться с актуальной редакцией закона и профильным юристом.