title: What is better approach to the next DynamoDB usage case?
body: <p>Imagine the next ordinary situation. We have two types of users - seller and buyer. Seller can create and edit only his offers. Offers can be in two states - active or not.
  Buyer can see only active offers of all sellers.
  What is a better approach to the task using DynamoDB?
  1) Create two DynamoDB instanses, one for active offers and one for not active ones.
  In this approach Primary key for both tables:</p>
  
  <pre><code>{
    partition: sellerId,
    sort: offerId
  }
  </code></pre>
  
  <p>Proc and cons I see:</p>
  
  <ul>
  <li>(+) receiving own offers for seller is simple (query by partition
  key)</li>
  <li>(+) receiving active offers for buyer is simple (scan corresponding table without conditions)</li>
  <li>(+) we can set different throughput for tables if buyers >> sellers etc</li>
  <li>(-) changing offer state is rather complex (delete and put operations)</li>
  </ul>
  
  <p>2) Create one table with "active" boolean field for an offer object.
  Primary key is the same:</p>
  
  <pre><code>{
    partition: sellerId,
    sort: offerId
  }
  </code></pre>
  
  <p>Index can be:</p>
  
  <pre><code>{
    partition: active,
    sort: offerId
  }
  </code></pre>
  
  <p>(not sure such index can work effectively)
  Proc and cons I see:</p>
  
  <ul>
  <li>(+) receiving own offers for seller is simple (query by partition
  key)</li>
  <li>(+) changing offer state is simple (put operation)</li>
  <li>(+) using only one table</li>
  <li>(-) receiving active offers for buyer can be complex (scan with condition) or we need additional throughput for index.</li>
  </ul>
  
  <p>So basically the question is whether using index with boolean partition part is ok or not and is there a possibility that one approach leads to a problems with scaling in future and the other one not (maybe I don't see evident drawbacks of any approach)</p>