В инженерном разборе архитектуры D1 описано разделение контрольной плоскости и пути выполнения SQL‑запросов. Операции создания и удаления базы данных требуют согласования метаданных, тогда как обращение к единому центральному хранилищу при каждом запросе стало бы узким местом и источником задержек.
Фиксация создания
В описанной схеме Durable Object инициализируется первым, после чего сведения о базе фиксируются в Postgres. Эта запись выступает в роли контрольной точки: база считается созданной с момента фиксации метаданных, даже если окончательный ответ клиенту ещё не поступил.
Восстановление состояния
Периодические сигналы от Durable Objects используются для сверки состояния базы и устранения возможных рассогласований. Метаданные маршрутизации в Workers KV обновляются с учётом допустимой задержки согласования между компонентами.
Для обычных SQL‑запросов система стремится опираться на распределённые метаданные и направлять выполнение к соответствующему Durable Object, чтобы минимизировать латентность. Если запись о маршрутизации отсутствует, предусмотрен резервный путь получения сопоставления, позволяющий найти исполнителя запроса.
Этот пример иллюстрирует, почему общая монолитная транзакция не подходит для всех операций в распределённой системе: необходимо явно определять момент фиксации результата и организовывать отдельные механизмы восстановления связанных состояний после отказов. Описанные детали относятся к конкретной реализации D1 и не претендуют на универсальность для всех баз данных.