That's kind of like saying "What kind of car will win the Baja 1000?". It depends.
Also, 100% uptime is not possible. You can get darn close, however
That being said, there are a few things that you will want to do.
1) What ever solution you put into place, make sure that you are measuring everything that you can. With metrics you can determine if you are over or under provisioned and take action. You can also see trends, and make informed choices before things start to break.
2) Redundancy is your friend. Geographic redundancy (splitting up the app into different data centers in different geographic regions), horizontal (splitting the app servers from the DB's and the content servers) and vertical (a few small with a load balancer is better then 1 big).
So, that's the 10k foot view.
Specifically, in your case, I would define a group of servers that could handle about 75% of your traffic. Possibly 2 - 3 Nginx servers (my personal choice, use what you are comfortable with) fronting a pair of DB servers (1 master, 1 Read only Replica). Use the web server to proxy back to some sort of FCGI or other app server. Make sure that the front end servers are serving your cached pages (you ARE caching, right??).
Now, you'll need to drop some sort of LB in front of this. A single will be fine, because...
You'll be setting up an copy of this in another datacenter. All read only DB replicas, unless you want to dig in and get master/master replication set up.
Use round robin DNS to split traffic between the DNS CNAMES of the two load balancers.
In case of failure at one of the DC, just swing the effected cname over to the up site.
This is going to be expensive and hard to do.
Honestly, most folks will just do it in a single DC, as it's simply not cost effective to go all of the way.
Personally, I'd start small, and see how it holds. It should be easy to add servers, and after a bit of time, you'll be able to see where your application needs the help.