Я обожаю тим-ревью, но даже с таким подходом, на одном из проектов пролетела бага, которая убила регистрацию(!)

А тесты на регистрацию не?

Да не наказываю я. Я нахожусь с другой барикады. Данный подход пока не позволил допускать такие проблемы.

ЗЫ даже если проект большой — команды дробятся на 4-5 человек, так что будут отвечать 4-5, а не 100 (точнее 4-5 + пару кто ревьюил)

Он знает возможные проблемы и их решения, что и для чего можно использовать

Тести показывают проблемы и как они решаются через код. Как это будет работать и реализовано решает команда, а не один человек (планирование «скоупа» работ и реализация). Ответственность несут тоже все. Написание контролируется тоже командой (code review, switch pairs and context). Нет hero-mode, он просто не нужен.

14. Четко разделяйте ответственность — за каждый участок кода должен отвечать один разработчик

Не работает. Человек может заболеть/уйти в отпуск/уволится. Тогда он становится узким местом в разработке (пример: один знает работу билинга — на него все молятся, ведь только он может его чинить). Команда вся должна быть в курсе всех частей проекта. Для решения подобных проблем используется система «review» кода перед принятием в основную ветку другим(и) разработчиком(ами). Также используется работа в паре и переключение с контекстных задач людей.

Да, правильно поняли. Это же кэш, а не хранилище данных. Никакой кэш не может дать гарантии на то, что данные там будут храниться вплоть до окончания TTL. Иначе его размер был бы неконтролируемым.

Тут я с Вами не согласен. Если мне нужен кеш (кусок данных для быстрого доступа), то я ожидаю, что он будет существовать «расчетное» мной время. Размер кеша — эта отдельная тема (для таких случаев отказываются от хеш-таблиц и добавляют сжатие из коробки). Система, которая не может это гарантировать тяжело рассматривать как кеш систему.

ybc имеет право на жизнь, но мне тяжело придумать применение его в реальном проекте. Тот же redis гарантирует, что данные будут хранится в кеше до наступления TTL (+/- 1 миллисекунда).

Добрый день. Возникло пару воросов:

1) Как управлять размером буфера? Его можно задать через конфигурацию?
2) Я так понял из-за циклического буфера ключи с TTL могут исчезать из кеша раньше назначеного времени? То есть никакой гарантии нет, что записаное в кеш там не уберется в одночасье, поскольку други процессы уже написали еще данных в кеш?

Еще бы хорошо увидеть сравнение (бэнчмарк таблицы) с memcached.org, redis.io и gibson-db.in (последний сжимает хранимые данные и использует дерево вместо хешей — хеш-таблицы на больших объемах страдают или от коллизий или от не эффективности использования памяти), что бы понять, «стоит ли игра свеч». Особенно интересно увидеть результаты, когда данные влазят в RAM, и когда нет.

Опять же есть:
support.loader.io/...le/18-variables
support.loader.io/...pression-syntax

и словари:
support.loader.io/...7-payload-files

Смотрите доку тут: support.loader.io/...getting-started