Add a comment

 

Re: When do you need a 3-tier architecture?

I don't think n-tier, or rather, tiers, are the way to go. For some features, it makes sense to have multiple layers of services. For other features, it doesn't. Why constrain your entire application to fit into n tiers when for some things it's overkill and for others it's not enough?

I personally prefer lots of small components, offering APIs or consuming messages, that do one thing and one thing only. These get plumbed together to make a single service. With the right deployment environment, new services are simple to add. Horizontal scaling becomes much easier, with performance problems being localised to single services, and much easier to address, since drastic changes like rewrites and complete datastore changes are feasible. Code bases remain small and simple, and can be written in the right language using the right technologies for the job - a comet API might use NodeJS while the authentication service uses Scala. If it turns out that you chose the wrong database for a service, it's easy to replace, we replaced the database of a feed service in a large social network with zero downtime in only a few months, including all the work that was done in performance testing and proving that the new database was the right tool for the job.

Re: When do you need a 3-tier architecture?


Title
Body
HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
Name
E-mail address
Website
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).