I need advice on designing and planning a project

Hi guys.

This is not the typical Indie Hacker route, but things came this way. I presented a prototype for a public administration, and the thing kept going.

I am in a situation in which I am about to eat more that I can diggest, and of course I need your help.

This project consists in a network of displays (kiosk-like) that need to display certain content that will be updated every 30 second via ajax. Not real time and not similar, but a taste like this (https://ftx.com/trade/BTC-PERP). Basicly new little promos.

This network will potencially surpass a thousand of nodes, and has also subnets (in which there are common content for all the nodes in within). It also expected to surpass +30.000 publishers and ~80.000 promos a day.

This is out of my confort zone, because is just me alone and I fear scalability issues in the future and taking the wrong decisions in the begining.

How would you face this project?

how woud you prepare the structure initially?

what would you do to make sure you won't have critical problems as you add more nodes?

Does it make sense to split something at database-level or server-level?

Technically I can't split the subnets because I should keep information relative to nodes, promos and publishers together.

Any advice/suggestions/tips is more than welcome. Thanks.

PD: I did the prototype with Ruby on Rails

  1. 3

    If you're just updating with a text based payload I don't think you're really going to run into scaling issues given that your application doesn't do anything too crazy per request.

    On the consumer side given say 2,000 terminals updating every thirty seconds. that's only 4,000 network requests a minute or 66 requests per second. which is not really a lot.

    On the publisher side, if you've got 80,000 requests per day assuming they happen say scattered / concentrated within the span of 6 hours you're only looking at like ~4 requests per second which is really nothing.

    So a total of around 70 requests per second.

    That's not really a big worry although I can't speak much for what those individual operations would entail, can you give any more info on that?

    1. 1

      Sorry to be this late, I had a busy week and I left this unanswered.

      Your message was really what I needed to hear. It is a kiosk-like (think of this screens that you see in McDonalds) but they get updated more quickly based on user interaction.

  2. 2

    I agree with @koaty regarding the scale and the fact that it should be easily supported using pretty much any technology, but here are some performance related things to consider:

    • RoR is inherently poor at performance. It's not impossible to make it handle bigger loads - but its basic style and eco-system are not performance oriented, especially when using ActiveRecord over SQL databases. If you are comfortable with python/JS they are far more performant (out of the box) and only slightly less easy to write. There's really no need for bigger cannons like Go - but your ease of development is key. If RoR is the only thing you're comfortable with - stick to that.
    • Make sure your app is stateless and on a separate machine from your database. That will make scaling the app itself horizontally much easier in the future.

    Good luck!

  3. 2

    regarding the question on scalability, I definitely ditto what @koaty said in his comment -- you aren't dealing with too many requests and the complexity needed to process the requests themselves isn't that bad, which most modern web frameworks can handle.

    However, if you do begin to notice some points of agony in your system a simple solution would be to cache similar responses, I know you mentioned them being not similar but if there are a cluster of nodes requesting the same data, that might be a small fix to ease the load off the actual app. You also may be able to increase the number of app server workers, use '.includes' in any complex DB query, try to daemonize any time-consuming process that is not important. there are many ways to improve your app's scalability.

    That being said, you do need to be careful not to fall into the trap of premature optimization, I like to follow the philosophy of "make it work, make it clean, make it fast", so I suggest you turn the prototype into a robust product before worrying about any of that.

    I am currently the sole backend engineer on a product being developed under the eyes of some major organizations so I definitely feel where you're coming from, my product is also written in rails so feel free to shoot me an email if you want to go into a bit more detail!

    1. 1

      Sorry to be this late, I had a crazy time, and I postponed the answer. Right now I am rebuilding the proof of concept that I had I something more "professional". So far I thin I will use an application server and a database server in order to separate logic and date, and keep everything neat for latter stages. How do you use caching? Redis? How is approach? Thanks again.

      1. 1

        the easiest approach I've seen for caching http requests was faraday, which gives you a great way to work with caching in your rails app while using common cache stores like Redis or Memcache. I've read a few articles that says this path is the most customizable so it can fit any specific needs that you may have. Personally speaking, we haven't gotten to a point where we need to cache and scale so my understanding is very limited with regards to implementation, curious if you've found anything promising though

Trending on Indie Hackers
Indie Hackers is now an invite-only community 74 comments The Challenge: $10,000 MRR in 30 Months 41 comments Do you *like* Twitter? 34 comments 26 B2B Cold Outreach Templates - all for free... 🤝🏾 16 comments Let me review your web app 13 comments I founded CircleCI (valued at $1.7B) and Darklang. AMA! 11 comments