О справочнике

Главная · Редакционный стандарт

Справочник помогает инженерам и архитекторам выбирать и проектировать системы обработки данных, понимать их ограничения и готовиться к техническим обсуждениям. Примеры охватывают FinTech, iGaming и высоконагруженные системы.

Реальные и учебные архитектуры

Корпоративный кейс опирается на опубликованные сведения конкретной организации и относится к указанному времени. Источник может описывать только часть системы: его нельзя дополнять предположениями и представлять их как факт. Учебные схемы и walkthrough иллюстрируют возможное решение и не описывают deployment компании, если это прямо не подтверждено источником.

Категории достоверности

• FACT — конкретное утверждение подтверждено указанным источником в обозначенных версии и контексте.
• INFERENCE — инженерный вывод или рекомендация на основе фактов и технических принципов; применимость зависит от требований и условий эксплуатации.
• HYPOTHETICAL — учебный пример, моделируемый сценарий или иллюстративная архитектура.
• UNKNOWN — информации недостаточно для подтверждения утверждения. Отсутствие публикации не доказывает отсутствия механизма.

Категории используются там, где они меняют смысл утверждения; необязательно маркировать каждое предложение. Ссылка на источник не делает всю статью FACT.

Источники и дата проверки

Предпочтение отдаётся первичным материалам: документации продукта, публикациям организации, исходному коду и оригинальным докладам. Ссылку ставят рядом с утверждением; проверяют предмет, дату, версию и границы подтверждения. Реестры и исторические отчёты сохраняют результаты и ограничения проверки. Открытие ссылки само по себе не проверяет её смысл и не доказывает текущую архитектуру компании.

Дата проверки означает, когда автор сопоставил материал с источниками в указанном объёме. Это не дата публикации и не гарантия, что информация останется актуальной. Для новой проверки фиксируются её собственные дата и результат; старые результаты не переписываются.

Числа, тесты и рекомендации

Условные TPS, latency и SLA в учебных сценариях — параметры модели, а не реальные измерения или обязательства. Результаты benchmarks требуют методики, конфигурации, нагрузки, единиц и ссылки на evidence. Документированная гарантия продукта, локальный тест и проверенная end-to-end гарантия — разные вещи: область каждой указывается отдельно. Невыполненный тест остаётся непроверенным.

Инженерные рекомендации — отправная точка для оценки trade-offs, а не универсальные правила. Проверяйте их на своих требованиях, отказах, нагрузке, версиях и ограничениях.