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

Исходный код той системы мне недоступен, но, скорее всего, проблема связана с особенностями реализации внутри неё. Вероятно, ответ на запрос создания сущности возвращается до полного завершения транзакции в базе данных — например, внутри транзакции, а не после. В таком случае, хотя клиент уже получил подтверждение о создании, сама сущность ещё не видна для последующих операций.

Этот случай стал хорошим напоминанием: даже при успешном ответе от API нельзя всегда полагаться на мгновенную консистентность данных на стороне сервера.

• 4 - message_type
• 2 - field в message
• 5 - enum_type
• 8 - service

try (InputStream is = ...) {
DescriptorProtos.FileDescriptorSet fileDescriptorSet =
DescriptorProtos.FileDescriptorSet.parseFrom(is);

for (DescriptorProtos.FileDescriptorProto fileProto : fileDescriptorSet.getFileList()) {
// Получаем SourceCodeInfo с комментариями
DescriptorProtos.SourceCodeInfo sourceCodeInfo = fileProto.getSourceCodeInfo();

// Создаем карту: path -> комментарии
Map<List<Integer>, String> pathToComments = new HashMap<>();
for (DescriptorProtos.SourceCodeInfo.Location location : sourceCodeInfo.getLocationList()) {
if (location.hasLeadingComments() || location.hasTrailingComments()) {
List<Integer> path = location.getPathList();
String comment = location.hasLeadingComments()
? location.getLeadingComments()
: location.getTrailingComments();
pathToComments.put(path, comment);
}
}

// Обходим поля в сообщениях
for (int msgIndex = 0; msgIndex < fileProto.getMessageTypeCount(); msgIndex++) {
DescriptorProtos.DescriptorProto messageProto = fileProto.getMessageType(msgIndex);

for (int fieldIndex = 0; fieldIndex < messageProto.getFieldCount(); fieldIndex++) {
// Path для поля: [4, msgIndex, 2, fieldIndex]
// 4 = message_type, 2 = field
List<Integer> fieldPath = Arrays.asList(4, msgIndex, 2, fieldIndex);
String comment = pathToComments.get(fieldPath);

DescriptorProtos.FieldDescriptorProto fieldProto =
messageProto.getField(fieldIndex);
System.out.println("Field: " + fieldProto.getName() +
", Comment: " + comment);
}
}
}
}

1. Потенциальный – используеется в тестовых целях, альтернативный – резервный ключ
2. Потенциальный – может стать первичным ключем, альтернативный – вторичный уникальный ключ
3. Потенциальный – ключ который рассматривают в качестве вторичного, альтернативный – устаревший ключ
4. Потенциальный – используется для идентификации данных, альтернативный – используемый для шифрования

Имеется функция написанная на kotlin
fun findKotlinDev(departments: List): Employee {
return departments
.map { it.employees }
.flatten()
.first { it.position == "KOTLIN_DEVELOPER" }
}
можно ли что-то улучшить?

1. Заменить функции высшего порядка (map, flatten, first) на циклы for, чтобы улучшить производительность.
2. Добавить asSequence перед вызовом .map { it.employees }.
3. Улучшения не требуются.
4. Удалить вызов flatten, так как он не несет пользы и замедляет выполнение кода.

1. Использование UPDATE с условием WHERE и RETURNING:

UPDATE table_name
SET column_name = column_name + 1
WHERE id = $1
RETURNING column_name;

Этот подход гарантирует атомарность операции инкремента для конкретной записи, идентифицируемой условием WHERE (например, по первичному ключу id). Каждый поток выполняет UPDATE с одним и тем же условием WHERE, и PostgreSQL обеспечивает согласованность данных, сериализуя конкурирующие операции. Оператор RETURNING возвращает обновленное значение поля.

В Cassandra используется другой подход. При проектировании нужно учитывать, что запрос должен получить все необходимые данные за один раз — из одной таблицы. Поэтому сначала проектируются все возможные запросы, а уже под них создаются таблицы. Таким образом, в Cassandra создание структуры БД начинается с определения запросов.

1. Retry pattern
2. Circuit Breaker pattern
3. Rate Limiting pattern
4. Throttling pattern
5. Bulkhead pattern
6. Fallback Cache pattern
7. Null Object pattern
8. Priority Queue pattern
9. Leader Election pattern
10. Queue-Based Load Leveling pattern
11. Health Endpoint Monitoring pattern

Шаблоны масштабируемости

1. Load Balancer pattern
2. Cache pattern

• Client caching 
• CDN caching
• Web server caching
• Database caching
• Application caching
• Cache-aside
• Write-through
• Write-behind (write-back)
• Refresh-ahead

3. Materialized View pattern
4. CQRS pattern
5. Competing Consumers pattern
6. Sequential Convoy pattern
7. Federation (functional partitioning) pattern
8. Sharding pattern
9. Static Content Hosting pattern

Шаблоны доступа к распределенным данным

1. Interservice Communication pattern
2. Column Schema Replication pattern
3. Shared Data pattern

Шаблоны обеспечения безопасности

1. Gateway Offloading pattern
2. Gatekeeper pattern

Шаблоны переиспользования общего кода

1. Code replication pattern
2. Shared library pattern
3. Shared service pattern
4. Sidecar pattern

Шаблоны интегрируемости

1. External Configuration Store pattern
2. Anti-corruption Layer pattern

Шаблоны развертываемости

1. Blue/green pattern
2. Rolling upgrade pattern
3. A/B Testing pattern
4. Canary Testing pattern
5. Feature Toggle pattern

Шаблоны тестируемости

1. Dependency Injection pattern
2. Test Pyramid pattern
3. Testing Honeycomb pattern
4. Contract Testing pattern

Шаблоны согласованности чтения/записи

1. Synchronous Replication pattern
2. Pinning User to Master pattern
3. Fragmented Pinning pattern
4. Master Fallback pattern
5. Server Wait pattern
6. Client Polling pattern
7. Push to Client pattern
8. Loading screen pattern
9. Confirmation screen pattern
10. Fake It pattern

В Data Lake сохраняют данные в неструктурированном виде (в формате источника) в так называемом озере (Lake).

В нем видны:

1. Тренды - уязвимости с количеством репостов по соцсетям
2. Уязвимости
3. Исследователи уязвимостей

Обратный маневр Конвея: Продумайте лучшую архитектуру системы, а потом измените структуру компании так, чтобы она соответствовала архитектуре системы.

Плюсы:

1. Бесплатный пока бета
2. Суточный лимит 20 миллионов токенов и много запросов
3. Прилежный
4. За час он создал реактивный гейтвей https://github.com/batsura-sa/reactive-gateway-project

Минусы:

1. Требует VPN

1. Advisory lock - придумываем константу и используем pg_advisory_lock и pg_try_advisory_lock
2. Создаем таблицу блокировок и в этой таблице создаем запись. Если запись создана, то блокировка успешна. Для удаления блокировки удаляем запись.
3. Можно переиспользовать shedlock и соорудить что-то типа https://github.com/batsura-sa/distributed-lock-shedlock/blob/master/src/main/java/org/j262/lock/api/DistributedLock.java

Рассматриваю варианты:

1. Citus https://github.com/citusdata/citus
2. Apache shardingsphere https://github.com/apache/shardingsphere
3. Pg-sharding https://github.com/pg-sharding/spqr
4. Yuogabytedb https://github.com/yugabyte/yugabyte-db

Какие еще есть варианты?

Интересные алгоритмы поиска партиций:

1. Table Function. Храним сопоставление партиций узлам.
2. Consistent hashing.
3. Rendezvous hashing или наибольшего случайного веса. С Rendezvous клиент может посчитать хэш не просто от ключа 364, а хэш от пар. 364 и нода 1, 364 и нода 2 и выбрать максимальное число.