Какой объем таблиц используется в работе микросервиса?

Ага, слушай, про эти ваши микросервисы. Тут, бля, главный принцип — не наебаться самому себе с данными. Объём, которым один такой сервис управляет, обычно — десятки гигабайт, не больше. А то потом agility, ёпта, накроется медным тазом, и с резервным копированием начнётся пиздец, волнение ебать.

Смотри, как в жизни бывает, чувак:

• Сервис пользователей (UserService): Ну, там от силы 1-50 ГБ. Даже если юзеров овердохуища, профили — штука лёгкая.
• Сервис заказов (OrderService): Вот тут уже посерьёзнее, 10-100 ГБ. Заказы-то плодятся как кролики.
• Сервис сессий (SessionService): 1-10 ГБ, и то это данные, которые живут недолго, volatile, как говорится. Пришёл, вышел, чих-пых тебя в сраку — сессия умерла.
• Справочник какой-нибудь (CatalogService): Да похуй, до 1 ГБ. Каталог товаров, конфиги — ерунда.

А теперь, бля, золотое правило, выучи как «Отче наш»: если какая-то таблица подползает к 100 ГБ — это не просто сигнал, это охуенно громкий сиреной в ухо: «Чувак, твоя архитектура просит пощады!».

Что делать? Э, бошка, думай! Варианты есть:

1. Партиционирование. По дате, например. Старые заказы за 2015-й год — в одну кучу, свежие — в другую. Удобно искать и чистить.
2. Архивация. Всё, что старше трёх лет — нахуй в холодное хранилище, в тот же S3. Зачем тебе в оперативной базе держать данные, к которым раз в год обращаются?
3. Шардинг. Ну, это уже для крутых парней. Когда один сервис уже не тянет — дели его базу горизонтально. Серьёзная движуха.

Пример из жизни, чтобы не быть голословным: Был у нас PaymentService в одном магазине. Таблица с транзакциями раздулась до 80 ГБ. Запросы начали тормозить, админы — бздеть. Что сделали? Впендюрили партиционирование по месяцам. И всё, ёпта! Производительность SELECT по свежим платежам — огонь. А старьё, которому больше года, архивируется автоматом. Красота, а не жизнь. Просто надо головой думать, а не ждать, пока всё наебнётся.