Миграция с Supabase на VPS PostgreSQL без downtime: dual-write, strangler pattern и SSR read-path

TL;DR Мигрировал продакшн базу с Supabase на VPS PostgreSQL прямо на работающем проекте — без остановки, без потери данных. Заодно перенёс авторизацию через strangler-подход и убрал Supabase из SSR read-path. Расскажу три инженерных решения с кодом.

https://habr.com/ru/articles/1011134/

#PostgreSQL #Supabase #Nextjs #миграция_баз_данных #strangler_pattern #SSR #вебразработка #маркетплейс #авторизация #dualwrite

«Два стула» для данных: как мы боремся с рассинхроном в Rust-сервисе между Solana и PostgreSQL

Представьте: вы строите систему верификации дипломов. Требования простые — данные должны быть неизменяемыми (привет, блокчейн) и при этом быстро доступными для запросов (привет, PostgreSQL). Казалось бы, идеальное решение — писать в оба хранилища. Но дьявол, как всегда, кроется в деталях. Наш проект использует паттерн двойной записи (Dual-Write): Solana — гарантирует неизменность и прозрачность данных о выданных дипломах PostgreSQL (Supabase) — обеспечивает быстрые выборки и сложные запросы Звучит красиво на архитектурных диаграммах, но в production всё не так радужно. Главная проблема — частичные сбои . Транзакция в Solana прошла успешно, диплом записан в блокчейн навечно, а вот запись в PostgreSQL упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает. Сегодня я покажу, как мы столкнулись с этой проблемой лицом к лицу и какие паттерны применили для её решения. Чтобы стулья не разъехались

https://habr.com/ru/articles/966194/

#rust #postgresql #solana #dualwrite #web3 #распределенные_системы #transactional_outbox #saga_pattern #консистентность_данных #архитектура

Dualwrite – Beware of the reverse

I am setting up Dualwrite at a customer and I got an issue the other day. The customer wants to be able to create customers from Dynamics 365 CE and syncing them to Dynamics 365 for FO. We had done all of the initial syncs and done multiple test for creating Accounts in CE and the synced perfectly to FO.

When I was trying to figure out a way to manage Financial Dimension population while creating accounts I tried creating the customer directly in FO, just to test a thing… and it failed!!

I tried again from CE and it worked… but not from FO. We had been so focused on testing one direction but not the other… Doh!

So, what was the issue? I got this error:

and then it continued with a stack trace… Hmmm…

So I started brainstorming with a colleague: It is obviously a data type missmatch and when I turn off the mapping for Account, it works. Going through the mapping we had added a few transform mappings so we started there. It turns out that all of these we 1 to 1 mappings. The problems was that there three fields were not on the initial “customer creation sidebar”. In CE these were made mandatory but in FO, they were not.

I took a look at the mappings for these 3 fields and one stood out. It had no mapping for the empty value.

This meant that when going from FO to CE I tried to convert and empty string to an integer and since there was no transform for the empty field and no default it could not be written to CE.

The easiest way to add an empty mapping to null is to edit the JSON version of the mapping (I did not know this was possible until a short while ago)

Add the last line and do not forget the comma at the end of the previous line

That was it… I saved it and restarted the mapping. We verified it… Worked!!!

That was it for today… see you around

#DualWrite #Dynamics365ForFinanceAndOperations #Dynamics365ForSales