title: Best practice/Storage selection for CQRS/Event sourcing architecture
body: <p><strong>Task.</strong> Build scalable high load application with CQRS/Event sourcing architecture.</p>
  
  <p>Let's assume it's free advert board with lot of online users. So user should be able to:</p>
  
  <ol>
  <li>Register/Login</li>
  <li>Add/Update/Delete advert</li>
  <li>See the list of adverts</li>
  <li>Search for adverts</li>
  <li>Analyze adverts after some time/Reproduce each app state from Event Store.</li>
  </ol>
  
  <p><strong>My thoughts.</strong></p>
  
  <p>I would think about using of something like:</p>
  
  <ol>
  <li>Cassandra/MongoDB... - Store Events</li>
  <li>Kafka/Redis/Hazelcast/RabbitMQ... - Event queue</li>
  <li>Elastic Search + Cache(e.g. Redis) - for View</li>
  </ol>
  
  <p><strong>Questions.</strong></p>
  
  <ol>
  <li>What's cons/pros of using one against another for each step? Or maybe combine Event Storage with queue (E.g. use Kafka as queue and long term event storage)?</li>
  <li>Does anyone has proven stack and can share experience for CQRS/Event sourcing architecture ? </li>
  </ol>