Как хранились заказы в микросервисе?

Что проверяют

Это вопрос о вашем реальном проекте, и по нему проверяют, понимаете ли вы решения, принятые в сервисе, или просто работали рядом. Следом почти всегда идут уточнения: как обеспечивалась согласованность с оплатой и складом, что было при двойной отправке заказа.

Как отвечать

Рассказывайте про свой сервис, но по понятному каркасу:

• хранилище и почему: чаще всего PostgreSQL или SQL Server через EF Core, у сервиса своя база, и другие сервисы в неё не ходят. Если был MongoDB, объясните, чем подошла документная модель;
• модель: заказ как агрегат, Order и OrderItem отдельными таблицами, цена и название товара копируются в позицию на момент покупки, деньги в decimal, статус как перечисление с понятными переходами;
• конкурентные изменения: оптимистическая блокировка через rowversion в SQL Server или xmin в PostgreSQL, в EF Core это concurrency token и DbUpdateConcurrencyException;
• связь с другими сервисами: событие OrderCreated публикуется через transactional outbox, чтобы запись в базу и отправка в брокер не разошлись. В .NET это часто MassTransit с RabbitMQ или Kafka;
• распределённый процесс: оплата и резерв товара через сагу с компенсирующими действиями при отказе;
• чтение: для тяжёлых отчётов или поиска отдельная read-модель или реплика.

Нужны ваши подробности: сколько заказов в день, размер таблиц, что тормозило и что меняли. Если за хранение отвечала другая команда, так и скажите, расскажите, что знаете о её решениях и как спроектировали бы сами. Это честнее и выглядит лучше, чем выдуманная архитектура, которая развалится на втором уточнении.

Где спотыкаются

Отвечают теорией «можно так, а можно этак». Вопрос в прошедшем времени, от вас ждут конкретного выбора и его причины.

Хранят ссылку на товар без снимка цены. Товар подорожал, и старый заказ в истории внезапно стоит другую сумму.

Пишут в базу и публикуют событие двумя независимыми операциями. При падении между ними заказ есть, а склад о нём не узнал, и без outbox это не лечится.