Что хотят услышать интервьюеры:

Архитектуру master-slave для чтения и записи обычно применяют, когда нагрузка на чтение заметно выше, чем на запись, и нужно горизонтально масштабировать именно чтение. Мастер отвечает за запись и является источником истины, а слейвы обслуживают запросы на чтение и помогают разгрузить основную БД. Такой подход также полезен для повышения доступности и для отдельных задач аналитики или отчетности.

Определение:

Master-slave схема — это вариант репликации, при котором все изменения данных выполняются на главной базе данных, а затем копируются на одну или несколько реплик. Запись идет только в мастер, чтение можно распределять между слейвами. Это позволяет разделить нагрузку, но обычно приводит к задержке между записью и появлением данных на репликах.

Пример использования:

Интернет-магазин получает много запросов на просмотр карточек товаров и каталога, но сравнительно мало операций оформления заказа. В таком случае запись заказов и изменений остатков выполняется в мастер, а чтение каталога и карточек товара — со слейвов.

# Концептуальный пример: чтение и запись через разные подключения

def get_product(product_id):
    # чтение из реплики
    return slave_db.query(
        "SELECT id, name, price FROM products WHERE id = %s",
        (product_id,)
    )

def create_order(user_id, items):
    # запись в мастер
    master_db.execute(
        "INSERT INTO orders (user_id, status) VALUES (%s, %s)",
        (user_id, "new")
    )

Пояснение кода:

В примере функция get_product отправляет запрос на чтение в реплику, чтобы не нагружать мастер. Функция create_order пишет только в мастер, потому что именно он принимает изменения данных. В реальной системе после записи важно учитывать, что реплика может обновиться не мгновенно, поэтому сразу после критичной записи иногда нужно читать именно из мастера.

Ключевые моменты:

Подходит, когда чтений существенно больше, чем записей.
Мастер используется для записи и гарантирует актуальные изменения.
Слейвы помогают масштабировать чтение и разгружать основную БД.
Есть риск чтения устаревших данных из-за асинхронной репликации.
Для сценариев с частыми конфликтами записи или строгой консистентностью такая схема может быть неудобна.
Часто применяется вместе с балансировкой чтения и переключением на мастер для критичных операций.

В каких случаях рекомендуется применять архитектуру с разделением базы данных на мастер и слейв для чтения и записи данных?