Ниже — сопоставление трёх парадигм через призму реализации системы бронирования билетов (например, для концерта/поезда/авиарейса). Для каждой парадигмы опишу: какие структуры данных логично выбрать, как организовать мутируемое состояние (и защиту от гонок/инвариантов), типичный поток брони и плюсы/минусы подхода.

1) Процедурная парадигма

Модель данных
Простые наборы структур/записей (record/struct): Event { id, date, seats: array }, Seat { id, status, price }, Booking { id, eventId, seatIds, userId, status }.В памяти — массивы/хеш-таблицы: eventsById: map, bookingsById: map, либо хранение в реляционной БД (таблицы events, seats, bookings).Подход к мутируемому состоянию
Центральный (глобальный) mutable state: функции оперируют на общих структурах и изменяют их напрямую.Контроль консистентности через транзакции или блокировки на уровне функций/БД:в однопоточном простом приложении — критические секции (mutex) вокруг операций резервирования;в многопоточном/распределённом — транзакции базы данных (ACID), row-level locks или optimistic locking (версионное поле).Типичный поток (псевдокод)
function reserve(eventId, seatId, userId):
if seats[eventId][seatId].status != AVAILABLE: return error
begin transaction
update seats set status = RESERVED where id = seatId and status = AVAILABLE
insert into bookings (...)
commitПлюсы
Простота реализации и понимания.Хорошо сочетается с реляционной БД и транзакциями.Минусы
Глобальное состояние сложнее тестировать и масштабировать.Лёгко допустить ошибки при конкурирующих изменениях без аккуратной синхронизации.

Когда подходит: небольшие сервисы, быстрый прототип, приложения тесно привязанные к РСУБД.

2) Объектно‑ориентированная парадигма

Модель данных
Объекты/агрегаты с инкапсулированным состоянием:Event (агрегат) содержит коллекцию Seat-объектов и методы вроде reserveSeat(user, seatId).Seat: поля id, status, методы markReserved(), markBooked().Booking, Customer, Payment — отдельные классы.Репозитории (Repository pattern) для загрузки/сохранения агрегатов: eventRepository.load(eventId) / save(event).Подход к мутируемому состоянию
Инварианты поддерживаются методами класса: изменение состояния только через методы (encapsulation).Согласованность:Внутри одного агрегата можно синхронизировать доступ (synchronized methods / mutex).Для распределённых/нескольких агрегатов — транзакции/сервисы домена.Часто используется оптимистичная блокировка: версия агрегата (version) checked-on-save.Domain-driven design: агрегат Event — граница транзакции (внутри агрегата гарантируется консистентность).Типичный поток (псевдокод ООП)
event = eventRepository.load(eventId)
result = event.reserveSeat(seatId, userId)
if result.ok:
paymentService.charge(...)
event.confirmSeat(seatId)
eventRepository.save(event) // проверка версииПлюсы
Чёткая модель предметной области, инкапсуляция инвариантов.Удобно расширять, писать unit-тесты (mock репозитория).Минусы
Может возникнуть избыточность/сложность проектирования (особенно с распределённостью).Нужно осторожно проектировать границы агрегатов, иначе сложность синхронизации вырастает.

Когда подходит: системы средней/большой сложности с богатой предметной областью, требованиями к инкапсуляции бизнес-логики.

3) Функциональная парадигма

Модель данных
Неизменяемые (immutable) структуры: records/алгебраические типы, persistent maps/sets/vecs.Состояние представлено в виде snapshot или как последовательность событий (event sourcing).Snapshot: State { events: map, bookings: map, seats: map } — каждая операция возвращает новый State.Event sourcing: лог событий (SeatReserved, PaymentSucceeded, BookingConfirmed); состояние восстанавливается через replay.Подход к мутируемому состоянию
Чистые функции описывают переходы: newState = reserve(state, eventId, seatId, userId) -> Either<Error, newState>.Сайд-эффекты (платёж, запись в БД) отдельно: эффектная оболочка/монады/эффектные системы.Для конкурентности:STM (software transactional memory) или atom/Refs с CAS (compare-and-swap) для атомарной замены snapshot.Actor model (Erlang, Akka): каждый Event/Flight — актор, обрабатывающий сообщения сериализованно.Event sourcing + optimistic appends: append-only log с проверкой последовательности/версии.Lenses/optics для удобного «обновления» вложенных неизменяемых структур.Типичный поток (псевдокод функциональный)
attempt = reserve(state, eventId, seatId, userId)
match attempt:
| Left error -> return error
| Right newState ->
persist(newState) // атомарно: CAS на ссылку/append event
performPayment(...) // отдельно; если откат нужен, append compensating eventПлюсы
Простота рассуждений о состоянии (каждая функция чиста), лёгкое тестирование.Event sourcing даёт audit trail, возможность восстановления и отладки.Хорошо для параллелизма/распределённости при правильно выбранной модели (акторы/CRDT/STM).Минусы
Требуется архитектурная дисциплина (разделение чистой логики и эффектов).Может усложнить привычные операции (например, rollback при платеже требует механизма компенсации).Производительность при частых копиях структур требует persistent DS и оптимизаций (структуры с шарингом).

Когда подходит: высоконагруженные распределённые системы, где важна предсказуемость, воспроизводимость, audit trail; также когда хочется безопасных параллельных вычислений.

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

Хранилище свободных/занятых мест:
Процедурно/ООП: boolean[]/map<seatId, status> или таблица seats; для больших сцен — bitmap или сегментированные структуры для быстрой выборки contiguous seats.Функционально: immutable bitset/persistent vector или set/bitset; в event sourcing — события seatReserved/seatReleased.Индексы по брони/по пользователю: hash maps/map<userId, list> — в любой парадигме.Масштабирование/распределённость:
Процедурный подход полагается на БД-транзакции и масштабирование БД.ООП + DDD: разделение агрегатов и CQRS (read models) — полезно для масштабируемости.Функциональный: event sourcing + CQRS, акторы или CRDT-ы для eventual consistency.Защита от двойного бронирования:
Процедурный: транзакция/row lock при смене статуса seat.ООП: synchronized внутри агрегата или optimistic locking (проверка version при сохранении).Функциональный: атомарный CAS на snapshot, STM, или сериализация операций на акторе/partition.

Краткие рекомендации по выбору

Нужна простота и вы используете реляционную БД: процедурный/прямой стиль с транзакциями подойдёт быстрее.Нужна выразительная модель домена и инварианты: ООП + DDD, агрегаты и репозитории, optimistic locking.Нужна воспроизводимость, audit trail, масштабируемость/параллелизм: функциональный подход с immutable DS и/или event sourcing + CQRS/акторы.

Если хотите, могу:

привести маленькие пример‑фрагменты кода (псевдо/на конкретном языке) для каждой парадигмы;спроектировать конкретную модель данных/схему БД и набор API для вашего сценария (авиа/концерт/поезд) с учётом ожидаемой нагрузки.