Data architecture for digital marketplaces

Question

I am building a digital marketplace app. I would like to know what the best practice design patterns are for the backend (No SQL) object store.

The primary characteristics of the app are as follows:

1. The app presents users with a series of editable lists (with CRUD functionality: create, read, update, delete).
2. There is a main marketplace (list of items viewable and editable with user-specific data. An example of this would be a list of products for sale. And every user would be allowed to enter their bid on the product. All the users might be able to see the other bids but only edit their own bid).
3. Users will have views of their own activity. And the ability to work from those lists. An example of this would be all unaccepted offers. Or all products being offered for sale by the user that have received bids from other users.

My question is, are there any guidelines for how to best design the data architecture when the back end is a No SQL object store like Firebase?

The following is an example of one such best-practice architecture I seek. However, it only deals with one list view. Those items added by a user but are only viewable to the user who created the items. Are there others?

NoSqlDataStore

root/
 |
 - users/
    |
    - uid-xxxxxxxxxxxxxxxxxxxxxxxxxxxx/
       |
       - items/
          |
          + Xxxxxxxxxxxxxxxxxxxxxabc123
          |
          + Xxxxxxxxxxxxxxxxxxxxxabc124
          |
          + Xxxxxxxxxxxxxxxxxxxxxabc125

Answer 1

NoSQL is a term that covers very different families of databases, such as column stores, document stores, key-value stores, graph databases,etc... each having very different best practices.

If you specifically target Firebase, it's a JSON objects database, i.e. a document store:

• The firebase website recommends best practices such as:
  • Use nested data sparingly / prefer flattened data
  • Use indexed data/keys when possible, to reduce data fetching
  • Joining flattened data in queries
• These practice match with more general JSON practices such as google's style guide
• Other recommendations for document database could be beneficial as well