Ми працюємо з протоколом AT Protocol (Bluesky). Нам необхідно розробити або адаптувати референсну реалізацію AppView — сервісу, який здатний зберігати та обслуговувати приблизно 500 ТБ даних, отриманих із “firehose” (потоку трансляції подій мережі).Попередня спроба реалізувати це рішення на базі PostgreSQL виявилася невдалою — база даних не витримала навантаження. Нам потрібен експерт, який візьме на себе повну відповідальність за вибір технологічного стеку для рівня даних (data layer) та розробку архітектури навколо нього.

Функціональні вимоги до AppView:

1. Інжестія потоку даних (Firehose ingestion): Безперервний інтенсивний потік записів (commits: пости, лайки, підписки, репости, блокування) з релеїв. Висока постійна пропускна здатність на запис без природного зворотного тиску (backpressure).
2. Соціальний граф (Social graph): Відстеження підписок, блокувань та ігнорувань (mutes). Критично низька затримка на читання (latency-critical), інтенсивне обходження графа (traversal-heavy), високе розгалуження (fanout) для побудови стрічки новин.
3. Обслуговування стрічки новин (Timeline / feed serving): Низька затримка читання за умов високої конкурентності. Вибір між стратегіями формування стрічки при читанні (fanout-on-read) чи при записі (fanout-on-write) залишається відкритим.
4. Агрегації та лічильники: Підрахунок лайків, відповідей та репостів. Дані з високою кардинальністю (high-cardinality), частими змінами (high-churn) та високим навантаженням на читання (read-hot).
5. Пошук та рекомендації: Повнотекстовий пошук по постах та визначення поточних трендів (trend detection).
6. Історичне/аналітичне сховище: Основний обсяг даних (близько 500 ТБ). “Холодні” дані, які скануються рідко та мають зберігатися окремо від оперативних (“гарячих”) даних.
7. Модерація та маркування: Швидкий пошук міток під час читання, а також можливість ретроактивного видалення контенту по всьому корпусу даних.

• Діагностика збою PostgreSQL: Перш ніж пропонувати альтернативи, необхідно чітко визначити, що саме зламалося в Postgres (write amplification, розростання індексів (index bloat), тиск vacuum, насичення з’єднань, вартість fanout-запитів чи структура зберігання). Пропозиція без детального аналізу причин збою Postgres не розглядатиметься.
• Вибір топології зберігання: Очевидно, це буде поліглот-архітектура (polyglot persistence). Необхідно створити чітку карту відповідності кожного типу навантаження конкретному рушію бази даних із технічним обґрунтуванням. Кандидати для оцінки (необов’язковий стек): ScyllaDB/Cassandra, ClickHouse, Redis/Valkey, FoundationDB, спеціалізовані сховища типу TigerBeetle, сервіси на базі RocksDB, об’єктні сховища + Iceberg/Delta для холодного тиру, OpenSearch/Meilisearch для пошуку, або графова БД (якщо доцільно).
• Розподіл на гарячі/холодні дані: 500 ТБ не можуть бути рівномірно “гарячими”. Потрібно визначити, що залишається на NVMe, що переходить на ємні диски, а що — в об’єктне сховище, та спроектувати механізм міграції даних.
• Проектування інжестії та бекфілу: Споживання firehose, гарантії порядку повідомлень, повторне відтворення/бекфіл після збоїв та ідемпотентність. Використання Kafka (або аналога) як буфера.
• Шардування: Спроектувати межі шардування в умовах мультитенантності децентралізованих мереж. Визначити ключ шардування (shard key) та проаналізувати його наслідки.
• Створення PoC (Proof of Concept): Підготовка двох альтернативних варіантів архітектури, проведення бенчмарків на реальних даних firehose та реальних шаблонах запитів із публікацією результатів.
• Розрахунок вартості (Cost Model): Створення моделі TCO на 3 роки, що враховує обладнання, хостинг та витрати на команду для підтримки системи.

• Досвід експлуатації розподілених баз даних обсягом 100 ТБ+ у продакшені, де ви особисто відповідали за схему та топологію.
• Практичний досвід роботи з високонавантаженими на запис та розгалуженими (fanout-heavy) соціальними архітектурами: стрічки новин, соціальні графи або масштабні системи обміну повідомленнями.
• Досвід роботи принаймні з трьома технологіями з переліку: ScyllaDB, Cassandra, ClickHouse, FoundationDB, Redis/Valkey, RocksDB, Kafka, Iceberg/Delta.
• Здатність аргументовано та в конкретних термінах пояснити специфіку збоїв PostgreSQL під такими типами навантажень.
• Впевнене володіння SQL та Python. Здатність читати код на Go, Rust та TypeScript (оскільки екосистема AT Protocol написана на них).

• Прямий досвід роботи з AT Protocol (запуск власного PDS, релея, AppView або генератора стрічок).
• Досвід роботи з аналогічними федеративними чи децентралізованими протоколами (ActivityPub/Mastodon на великих масштабах, Matrix).
• Досвід розгортання stateful-інфраструктури даних за межами великих хмарних провайдерів (hyperscalers).

• Конкурентну заробітну плату та соціальний пакет.
• Гнучкий графік роботи для збереження work-life balance.
• Робочий ноутбук із усім необхідним програмним забезпеченням.
• Бухгалтерський та юридичний супровід.
• Прозоре керівництво без бюрократії.