Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

For Techies: What size server, etc., will TM need to handle Model 3 reservations?

This site may earn commission on affiliate links.

AudubonB

One can NOT induce accuracy via precision!
Moderator
Mar 24, 2013
9,896
48,491
The thread title says most everything. This forum's members are nigh-unanimous in suggesting that reservations for the Model 3 will be an instantaneous roof-buster. Some points to consider:

* Extrapolating from the forum's members' actions to those of the general public is a perilous, but necessary, task.

* US trends and those from the rest of the world differ but need be taken into consideration.

* TM has acquired a reputation for HQ to being fair to poor at customer communications; reservation handling most definitely is one aspect of same.

* There are enough IT, etc., experts here for some of you to be able to have knowledgeable input as to what the appropriate course of action should be for a company like TM to properly plan for such an order influx.

What would you do?
 
I work in software development, therefore not the exact match for what is needed to estimate the IT infrastructure need. I would not dare to make a recommendation, but my gut feeling tells me, that Tesla IT will underestimate the demand. I would bet on their server going down under the load in the first 24 hour when the reservations open up for Model 3.
 
I'd assume they would use a farm of servers. That way they can add capacity practically on the fly. They will probably have several virtual servers on each physical server,
 
I'd assume they would use a farm of servers. That way they can add capacity practically on the fly. They will probably have several virtual servers on each physical server,

Sure, they can (and probably do) use clustering and fail-over redundant servers. However, there are multiply layers that can become bottleneck. It is one thing to handle the incoming connections in the web server layer, but your DB also need to be able to handle the connection numbers , or you need to use multiple distributed DB servers too. Then you may hit the bottlenecks of the network switches and routers. Large server farms like Google need to build up redundancy and distribution at every level.

Based on the WHOIS record their website seems to be hosted by Akamai:
https://www.akamai.com

This is a cloud service provider, so they could have a service agreement with them to grow the service on demand.
 
Last edited:
Sure, they can (and probably do) use clustering and fail-over redundant servers. However, there are multiply layers that can become bottleneck. It is one thing to handle the incoming connections in the web server layer, but your DB also need to be able to handle the connection numbers , or you need to use multiple distributed DB servers too. Then you may hit the bottlenecks of the network switches and routers. Large server farms like Google need to build up redundancy and distribution at every level.

Based on the WHOIS record their website seems to be hosted by Akamai:
https://www.akamai.com

This is a cloud service provider, so they could have a service agreement with them to grow the service on demand.
Akamai provides local front ends so that regardless of where you are geographically the experience is the same. Having a third party cloud provider store this kind of sensitive data is scary from a security standpoint.
 
It's likely to be much less a matter of how many resources they have allocated to it and much more a matter of how those resources are structured. You can throw a massive amount of computing power at an inefficient system and it still won't work well. What they are likely (hopefully) focusing on is building a well-designed, efficient reservation system that minimizes bottlenecks.
 
I think you are way over estimating model 3 reservation demand. Any basic level web hardware can handle thousands of transactions per second. How many model 3 reservations do you think they'll get? 50,000? 100,000? It's not like they're selling millions of iphones the second they go on sale. I could design and build a system to handle the M3 reservation load in my sleep. All it needs to do is collect basic contact info and a credit card. Done.
 
Akamai are actually quite good at scaling demand -- edge router caching was their original business. Between them and AWS, they probably deliver two thirds of the world's web traffic. I wouldn't worry about scaling of the backend, assuming they inform Akamai and pay for the capacity.
 
Honestly, I don't think I'd spend money to accommodate a load that is likely only going to last a few hours or days. Whatever they have is what they will use, I'm guessing. It doesn't make sense to me to spend money upgrading something that will only be used for a short period of time. If people can't get in right away, they'll have to try again later. The load demand will decrease as time goes on. Very low priority issue in my mind.
 
Honestly, I don't think I'd spend money to accommodate a load that is likely only going to last a few hours or days. Whatever they have is what they will use, I'm guessing. It doesn't make sense to me to spend money upgrading something that will only be used for a short period of time. If people can't get in right away, they'll have to try again later. The load demand will decrease as time goes on. Very low priority issue in my mind.
The front end would only be a small part of it. Presumably it would feed several databases: purchasing, manufacturing, accounting, etc.
 
Honestly, I don't think I'd spend money to accommodate a load that is likely only going to last a few hours or days. Whatever they have is what they will use, I'm guessing. It doesn't make sense to me to spend money upgrading something that will only be used for a short period of time. If people can't get in right away, they'll have to try again later. The load demand will decrease as time goes on. Very low priority issue in my mind.

I agree, not to mention that the server going down would generate lots of free publicity. Plus its not spur of the moment thing, if you're going to buy a car and you can't do it right that second its not like you just give up.

Course HankLloydRight is as is name says, right, the reservation system isn't going to be overly taxed its not that much traffic compared to alot of other things.
 
  • Funny
Reactions: Silvwarrior
If they should host it themselves, it would be possible with a few load balancers, 4-5 web servers and just one big database server. But it wouldn't be viable to refactor all of their infrastructure just for a few hours load.

Instead, they would probably outsource it. Queue systems like Queue-It uses Amazon's cloud for load balancing, and only let a specific amount of users into the server at the same time. So if Tesla's server(s) can handle e.g. 10.000 simultaneous connections, it would only let that many people in. The rest would sit in the queue on Amazon's cloud with no problems.
 
And think about it realistically -- how many people are going to be sitting at their computer, feverishly hitting F5 to be the first ones to reserve a Model 3? I'd guess there's no more than 500 of those types (and most of them are TMCers), and that's a very liberal guess. The rest of the folks probably don't care if it's today, tomorrow, or the next week or what reservation number they have -- once they decide to put in a reservation for a car they likely won't see for two or more years.

Building a web stack to handle 500 connections? You could do that on a web server machine from 15 years ago running IIS. ;)
 
Another thing we don't know yet (as far as I know) is how much the reservation price will be. The reservation numbers will vary greatly if the reservation price is $500 versus $2000+. I'm not sure what Tesla's goal is exactly as far as how many reservations they expect or want. I don't think a high reservation count (100,000+) would be desirable. We still don't know how many Model 3's they expect to deliver the first year. If they can't deliver all the reservations within the first year, I don't think that would be a good thing.

If the goal is for reservations to help with R&D and whatnot, there's no reason why they can't keep the price a bit higher.

- - - Updated - - -

And think about it realistically -- how many people are going to be sitting at their computer, feverishly hitting F5 to be the first ones to reserve a Model 3? I'd guess there's no more than 500 of those types (and most of them are TMCers), and that's a very liberal guess. The rest of the folks probably don't care if it's today, tomorrow, or the next week or what reservation number they have -- once they decide to put in a reservation for a car they likely won't see for two or more years.

Building a web stack to handle 500 connections? You could do that on a web server machine from 15 years ago running IIS. ;)

Agreed. I'm not planning on staying up late to put in a reservation. I'll probably do it sometime during the following weekend. I don't make enough money for the $7500 tax credit, so I'm figuring I should let someone else who does get in first.
 
I'm pretty sure Tesla is using some kind of Cloud hosting (the use of the Akamai content delivery network hints at this). Whether Amazon Web Services, Microsoft Azure etc. Any of these platforms ought to be able to scale automatically to handle the load.

As far as customer/credit card data security - yes this is a valid concern. Amazon does offer Payment Card Industry Data Security Standard compliant hosting (see here). I expect a number of other providers do as well.

Disclaimer - I work for an Internet hosting company that does this sort of thing, but not Amazon. I'm actually trying very hard NOT to plug my employer here on TMC.
 
I don't know about the first day of deposits, but I would imagine that Tesla could take up to 25,000 reservations in the first week. This assumes that the deposit is $1,000 - $1,500 for general production vehicles. Any lower than $1K and you'll get a higher cancellation percentage. I suspect Tesla will get a total of 100,000 deposits in 2016, and another 100,000 deposits in 2017.

The number of deposits is important because it will allow Tesla to easily raise additional capital for building out the M3 production line(s). It will also give credibility to Tesla's sales forecasts in 2018 and beyond. It will also give suppliers advance notice on the volume of parts that will be required.
 
The thread title says most everything. This forum's members are nigh-unanimous in suggesting that reservations for the Model 3 will be an instantaneous roof-buster. Some points to consider:
...
What would you do?

I agree with the roof-buster demand. For that reason I think Tesla will do something different this time around. I think they'll put all the reservations for the first week (or some other period of time) into a raffle for the queuing. That way there will be no big incentive to reserve on the first day, and no reason to crash their servers.
 
If they should host it themselves, it would be possible with a few load balancers, 4-5 web servers and just one big database server. But it wouldn't be viable to refactor all of their infrastructure just for a few hours load.

Instead, they would probably outsource it. Queue systems like Queue-It uses Amazon's cloud for load balancing, and only let a specific amount of users into the server at the same time. So if Tesla's server(s) can handle e.g. 10.000 simultaneous connections, it would only let that many people in. The rest would sit in the queue on Amazon's cloud with no problems.
This...I really hope they outsource and spec peak dynamic demand loading for at least 1M concurrent hits/connections to ensure they can handle without issue the first few hours of load.