Pull to refresh
4
Berektassuly Mukhammedali@Berektassuly

User

1
Subscribers
Send message

Гексагональная архитектура в Rust: отвязываем бизнес-логику от Solana

Level of difficultyMedium
Reading time8 min
Reach and readers10K

Представьте: вы строите сервис выдачи дипломов на Solana. Всё отлично, пока дело не доходит до тестов.

Внезапно оказывается, что для проверки бизнес-логики нужно поднимать валидатор, искать тестовые токены и молиться на стабильность сети. Знакомая боль?

В этой статье я покажу, как мы решили проблему, используя async-trait и dyn Trait. Мы превратили интеграционные тесты длиной в минуты в юнит-тесты, которые проходят за миллисекунды.

Узнать решение

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

Level of difficultyMedium
Reading time12 min
Reach and readers8.8K

Представьте: вы строите систему верификации дипломов. Требования простые — данные должны быть неизменяемыми (привет, блокчейн) и при этом быстро доступными для запросов (привет, PostgreSQL). Казалось бы, идеальное решение — писать в оба хранилища. Но дьявол, как всегда, кроется в деталях.

Наш проект использует паттерн двойной записи (Dual-Write):

Solana — гарантирует неизменность и прозрачность данных о выданных дипломах

PostgreSQL (Supabase) — обеспечивает быстрые выборки и сложные запросы

Звучит красиво на архитектурных диаграммах, но в production всё не так радужно. Главная проблема — частичные сбои. Транзакция в Solana прошла успешно, диплом записан в блокчейн навечно, а вот запись в PostgreSQL упала. Пользователь получил подтверждение, но половина системы о его дипломе не знает.

Сегодня я покажу, как мы столкнулись с этой проблемой лицом к лицу и какие паттерны применили для её решения.

Чтобы стулья не разъехались

Information

Rating
Does not participate
Registered
Activity

Specialization

Десктоп разработчик, Фулстек разработчик
Git
PostgreSQL
Python
Bash
Golang
Docker
Redis
MySQL
REST
CI/CD