Yo.!
для того чтоб в случае сбоя воставновить ваш объект вы обязаны писать в персистент хранилище и не асинхронно а "сию секунду", т.е. тут съэкономить не удастся

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

DPH
Я неоднократно играл с подобными схемами, выигрыш от варианта "update объекта в кэше, вставка изменения в базу" по сравнению с "update поля в базе" зачастую более чем в десять раз. Ну и, конечно, никаких блокировок (вернее, блокировка по объекту AppServer, но она очень быстрая).
неверю, геморой по синхранизации объекта с субд не окупится, расскажите plz что вы будете желать если после обновления объекта связь с субд пропала ?[/quot]

Гм, а зря не веришь. Синхронизация объекта с БД - элементарна:

в БД лежит начальное значение на некий момент времени,
при каждом изменении в отдельную таблицу в рамках транзакции пишется "дельта" (insert, без блокировок).
на AppServer в кэше живет только актуальное значение, кэш освобождается по времени или по переполнению, изменение кэша синхронизируется (это все практически бесплатно).
При откате транзакции кэш в AppServer, понятное дело, корректируется (что легко).
Если упал AppServer или значения в кэше нет - то новое значение рассчитываем по начальному и дельтам (единственная блокирующая транзакция, но очень редкая).

Реально на тестах такая схема показала примерно 2х кратный выигрыш при отсутствии конкуренции и 20ти кратный - при большой конкуренции по одному элементу. Да, разумеется, просто чтение значения в любом случае до БД не доходит (если есть запись в кэше).

Вообще, смотри архитектуру ebay, неэлементарные транзакции в больших системах - зло.

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

А 1000 операций в секунду можно получить и с бесплатным софтом и дешевым железом. Правда, на RAID придется потратиться. Ну и на программистов.
DB/2 Express C + log shipping в этом случае - замечательный выбор, все компоненты уже готовы, а кластер получается надежный и простой. И бесплатный...