gary4gar

Hello, We have an ReSt API that have been in use internally & now we have started opening it for our partners.

I have done the initial documentation by parsing our server logs to get the params, then tried the requests in POSTMAN. Once I had the params & responses, I documented them on http://developers.punchh.com/

Now, the docs there are 90% correct but sometimes they are out-of-date, wrong or have grammatical/typos in them which I fix but there is little bandwidth. I am wondering if I should outsource this work to technical writer(freelance/contract) to make sure API docs are solid as the will work on it dedicatedly vs my team who's primary focus writing code.

However, I am still not sure if this a good idea. how do other companies make sure that their API documentation is awesome? Looking for some advice on how to improve the API docs to they are easier to read:

URL: http://developers.punchh.com/

We are building a SaaS backend for restaurants using Rails. We integrate directly with POS, so each POS keeps sending customer orders that we store for later processing. we have this POS integration going at about 1,000 locations which send us about 3 Million individual customer orders on monthly basis.

for this write-heavy app, we store all orders in redis which is working beautifully. We are growing at incredible pace, we keep adding new restaurants with hundreds of locations that keep sending us crazy amount of data. Except there is one problem -- redis keeps running out of memory every month! As, everything which doesn't have to be in memory is in memory.

This is why we contemplating to switch to mysql. As we really don't need to keep all data in memory. here are we numbers of current redis database:

      used_memory_human:39.83G 
      dbsize: 34706870

Here is what we store in redis as Hash:

      id - integer
      location_id - integer
      stored_at  - timestamp
      token - string
      transaction_no - integer
      menu_items - string(comma seprated list of all menu items that customer ordered along with their price & Qty)
      order_amount - decimal
      order_subtotal_amount - decimal
      order_amount_payable - decimal
      order_datetime - timestamp
      employee_id - integer
      employee_name - string
      pos_type - string
      post_version - string
      restaurant_id - integer
      

So, looking for some advice on:

1. moving from redis to mysql is good idea? how will it effect us in long run as we will need to keep updating our indexes & partition scheme to cater to huge demand.

2. What other databases(relational or non-relational) would be suited for this use case than redis?

3. Or we are all wrong, as redis is made for storing this type of data. so, we just keep using redis & upgrading our machines every month?