3 ms·

Sorry. It's an Uber-for-X platform.

by oingo 11y ago

ascendantlogic 11y ago
Alright, what is the current architecture? Is the app just a dumb client and the intelligence lives on the server? Or is it flipped where the intelligence is all in the app and the server is just a central dumping ground for data? How In the course of regular usage, how many times would your app talk to your server? What would be the average size of those data transmissions? What would be the size of the edge cases? I'm not being pedantic for pedantry's sake. You need to have answers to all of these questions before you start thinking about capacity planning and high availability.
- oingo 11y ago
  I'm trying to draw up a schematic on paper, so this is it... 1) The app will essentially be the front-end. The user will only be using the app to make payments, view a map (with cars on the road), track their car, request / cancel a car, and provide feedback. So the heaviest usage would be from the server to the user and not the other way around. I'm not sure how much Google Maps uses up per minute and how much data is needed to push a car's new position to the phone. That would seem to me to be intensive though, especially over thousands of people. Edge cases would be 0 and 25 cars live on a map. Also, I currently have one droplet with DO. Am I supposed to have at least 3? (website, app, DB )
ascendantlogic 11y ago
But in the spirit of trying to be helpful, I will echo the sentiments I've seen elsewhere in this thread and say your best bet will be a reasonably sized box running HAProxy fronting at least 2 boxes running nginx + your API code. Since it is highly likely you have a DB you could also run an "internal" HAproxy box fronting multiple postgres servers that are doing bidirectional data sync but that complexity ramps up QUICKLY.
- oingo 11y ago
  I'll get back to your last one after giving it more thought. Here's a silly question about load balancers. What would happen if my requests weren't being "load balanced"?

Sorry. It's an Uber-for-X platform.

by oingo 11y ago

Sorry. It's an Uber-for-X platform.

Alright, what is the current architecture? Is the app just a dumb client and the intelligence lives on the server? Or is it flipped where the intelligence is all in the app and the server is just a central dumping ground for data? How In the course of regular usage, how many times would your app talk to your server? What would be the average size of those data transmissions? What would be the size of the edge cases? I'm not being pedantic for pedantry's sake. You need to have answers to all of these questions before you start thinking about capacity planning and high availability.

oingo 11y ago
I'm trying to draw up a schematic on paper, so this is it... 1) The app will essentially be the front-end. The user will only be using the app to make payments, view a map (with cars on the road), track their car, request / cancel a car, and provide feedback. So the heaviest usage would be from the server to the user and not the other way around. I'm not sure how much Google Maps uses up per minute and how much data is needed to push a car's new position to the phone. That would seem to me to be intensive though, especially over thousands of people. Edge cases would be 0 and 25 cars live on a map. Also, I currently have one droplet with DO. Am I supposed to have at least 3? (website, app, DB )

ascendantlogic 11y ago

But in the spirit of trying to be helpful, I will echo the sentiments I've seen elsewhere in this thread and say your best bet will be a reasonably sized box running HAProxy fronting at least 2 boxes running nginx + your API code. Since it is highly likely you have a DB you could also run an "internal" HAproxy box fronting multiple postgres servers that are doing bidirectional data sync but that complexity ramps up QUICKLY.

oingo 11y ago
I'll get back to your last one after giving it more thought. Here's a silly question about load balancers. What would happen if my requests weren't being "load balanced"?