План дальнейшего исследования¶
Очередь для Этапов 2–7. Приведённые ниже ссылки на документацию — стартовые точки; содержание этих страниц на Этапе 1 не проверялось и не используется как evidence для корпоративных FACT. Перед написанием выбирать versioned documentation и записывать release/access dates. Доступность URL и проверка утверждения — разные операции.
01 — Patterns¶
Сопоставить различия паттернов с первичными корпоративными материалами F01–F07, G01 и C01–C03. Для паттернов без подтверждённого deployment продолжить поиск, не назначать компанию по набору технологий.
Стартовые точки: Debezium Outbox Event Router, Martin Fowler: Event Sourcing, CQRS, Data Mesh, Databricks: Medallion. Для Lambda/Kappa искать оригинальные авторские публикации; для Data Fabric — чётко различать vendor-specific трактовки и проверяемые технические свойства.
Результат: 15 материалов по плану 01 с одним общим шаблоном сравнения.
02 — Storage¶
| Семейство | Официальные стартовые точки | Что проверить |
|---|---|---|
| Relational | PostgreSQL, Oracle, MySQL | MVCC/isolation, WAL/logs, indexes, replication и CDC |
| OLAP/cache | ClickHouse, Redis, DuckDB | Merge/dedup semantics, atomic operations, persistence и concurrency |
| Wide-column | Cassandra, ScyllaDB | Partitioning, consistency, LWT, compaction и write amplification |
| Document | MongoDB, Couchbase | Transactions, durability, sharding и query consistency |
| Search | Elasticsearch, OpenSearch | Refresh, mappings, shard sizing, indexing и recovery |
| Managed/time series | DynamoDB, TimescaleDB | Consistency modes, transaction limits, time partitioning и aggregates |
| Object storage | S3, MinIO | Object operations, consistency, lifecycle и совместимость |
| Table formats | Iceberg, Delta Lake, Hudi | Commit/catalog protocol, schema evolution, concurrency и compaction |
Результат: план 02, workload-based comparison и отдельная модель financial/betting storage. Нельзя делать вывод о гарантиях компании из одной документации используемого продукта.
03 — Processing¶
Стартовые точки: Kafka, Debezium, Flink, Spark, Airflow, dbt, NiFi, Camel, RabbitMQ, Pulsar, Schema Registry.
Проверить Connect и Streams в документации Kafka, Structured Streaming в Spark; версии API Dynamic Task Mapping/XCom в Airflow; window/watermark и checkpoint/sink guarantees в Flink. Проверить четыре сравнения из плана 03 на одинаковых сценариях.
04 — Reliability¶
Стартовые точки: transaction/isolation и replication документы PostgreSQL; delivery semantics Kafka и sink semantics Flink/Spark; документация Redis locks для анализа fencing и lease limits. Для требований: официальный текст GDPR, PCI SSC Document Library.
На этапе написания зафиксировать применимость, редакцию и дату, не переписывать юридические требования по памяти. Добавить fault matrix из плана 04, restore drills и сверку business effects.
05 — FinTech¶
Углубить F01–F07. Для idempotency добавить Adyen API idempotency и Stripe idempotent requests. Это API contracts, а не доказательство внутренних transaction boundaries.
Продолжить поиск в engineering publications Stripe, Adyen, Wise, Revolut, Nubank, PayPal, Block и Monzo. Приоритет пробелов: banking CDC, AML/KYC, clearing/settlement и recovery реального ledger. Запросы: компания + engineering + ledger/reconciliation/CDC/settlement; затем проверить автора и первоисточник.
06 — iGaming¶
Углубить G01–G05 и искать другие компании. Направления: Betfair/Flutter, Entain, DraftKings, Betsson, Evolution; gaming-компании допустимы, но их telemetry pipeline не подменяет betting wallet.
Пробелы: responsible gaming, re-settlement, bonus abuse, exposure aggregation и event-time corrections. Источники искать через engineering blogs и доклады именованных инженеров; vacancies и рекламные анонсы без архитектуры не принимать.
В реестре G05 должен получить техническое дополнение либо замену. G03 требует описания ledger semantics. Для конференционного источника записать speaker affiliation, event date, ссылку и timestamp/slide, не считать аннотацию просмотренным докладом.
07 — Case studies¶
Для каждого кандидата провести evidence review по шаблону. Сначала проверить data path и существенные trade-offs; затем consistency/failures, метрики, причины выбора и неизвестное. При изменении кандидата сохранить ID или явно отметить replacement, а не переписывать историю исследования.
До публикации: повторное открытие ссылок, дата и версия, provenance схемы, пять вопросов с ответами, оценка переносимости. 15 — целевое количество, а не основание для принятия слабого источника.