1) When it comes to recommendations people can obviously only answer from personal preferences. If it were me, I would create a cluster, but I really don't believe it's necessary for a forum only.

You need to really think about how big you believe your site can get and whether a distributed system is necessary for you. If it isn't then I would start of with 2-3 servers and just keep increasing the ceiling. You could get away with 1x4GB for the DB and 1x2GB Web. However, 3 is best with the third one being a replication slave for backup purposes.

If you set this up and you find yourself running out of memory but the CPU is fine, try looking at your architecture (eg, if you use Apache kick it to the curb and use NGINX) or put in a front end cache service like Varnish. If you believe there's nothing you can do to improve it further, then just resize your droplet to 4GB. It requires you to shutdown, but the resize process takes only a few seconds in my experience so from shut down to reboot you should only be down ~10 seconds.

2) I've never had such an experience with any US host that I've been with in the past decade. I'm not sure who you used in the past, but that's not a common policy. I serve millions of users per month from all over the world, and I've never received a complaint of this nature. Just make sure you're not using a service like CloudFlare because they do this and it's a reliably poor system.

3) You get root access to the operating system of your choice within the list that DO can provide. You're free to do with it as you choose.

Hi Dave. Would you mind some pointers how to do these, please, "whether a distributed system is necessary for you. If it isn't then I would start of with 2-3 servers and just keep increasing the ceiling. You could get away with 1x4GB for the DB and 1x2GB Web."

Do you mean two or three different droplets/servers in just one domain? Thanks.

Yes, 2-3 for one domain. The reason being that you don't want your web server and your SQL server to fight for resources (CPU/RAM) unless you have very little traffic or a lot of cached/static pages. You also want to have a backup of your database in case something goes wrong with the server suddenly. By using replication this means you'd lose only one seconds worth of data instead of 1-2 days. Also, you can point your website to the secondary-master so that your website stays online while you attempt to find out what went wrong with your primary-master.

Of course, these are only suggestions and it's dependent purely on the size of your web site, the application architecture and your needs. Some experimentation will be necessary to figure out the most cost effective solution for your website and budget, but DO makes that pretty simple by using the resize function. The 1x4G and 1x2G are only rough suggestions, you may be able to get away with less resources thus costing you less money.

To elaborate a little, instead of setting up your SQL database on the same server as your web application, you'd set it up on a new one and change the host to your primary mysql servers IP instead of localhost. Then you'd setup a master-master replication system for MySQL. The master-master setup is different from a master-slave because it allows you to write changes to either of your servers and have the other stay updated. What you don't want to do is attempt to write to both at the same time. That can lead to conflicts or errors.

http://c2journal.com/2013/01/24/step-by-step-guide-to-mysql-master-master-replication-without-downtime/