Asynchronously Decoupled Three-Tier Architecture

Question

Maybe I just expected "three-tier architecture" to deliver a little more than just a clean separation of responsibilities in the source code (see here)...

My expectations to such a beast that can safely call its self "three-tier architecture" are a lot higher... so, here they are:

If you were to build something like a "three tier architecture" system but this time with these, additional requirements and constraints:

• Up and running at all times from a Users point of view
  • Expect when the UI gets replaced
  • When other parts of the system are down, the UI has to handle that
• Never get into a undefined state or one from which the system cannot recover automatically
  • The system has to be "pausable"
• The middle-tier has to contain all the business logic
  • Obviously using an underlying Database, itself in the data-tier (if you like)
• The business logic can use a big array of core services (here in the data-tier, not directly accessible by the UI, only through business logic tier facade)
  • Can be unavailable at times
  • Can be available as many parallel running, identical processes
• The UI's may not contain any state other than the session in case of web UI's and possibly transient view baking models
• Presentation-tier, logic-tier and data/core-services-tier have to be scalable independently
• The only thing you can take for granted is the network

_{Note: The mentioned "core services" are heavy-weight components that access various external systems within the enterprise. An example would be the connection to an Active Directory or to a "stock market ticker"...}

1. How would you do it?

If you don't have an answer right now, maybe read on and let me know what you think about this:

• Sync considered harmful. Ties your system together in a bad way (Think: "weakest link"). Thread blocked while waiting for timeout. Not easy to recover from.
• Use asynchronous messaging for all inter-process communication (between all tiers). Allows to suspend the system anytime you like. When part of the system is down, no timeout happens.
• Have central routing component where all requests get routed through and core services can register themselves.
• Add heartbeat component that can e.g. inform the UI that a component is not currently available.
• State is a necessary evil: Allow no state other than in the business logic tier. This way the beast becomes manageable. While the core services might well need to access data themselves, all that data should be fed in by the calling middle tier. This way the core services can be implemented in a fire and forget fashion.

2. What do you think about this "solution"?

Answer 1

Yep its the way most large websites do it. Look at nosql databases, Google's bigtable architecture etc.

1. This is the general approach I'd take.

I'd use a mixture of memcached , a nosql-cloud (couch-db or mongo-db) and enterprise grade RDBMS systems (core data storage) for the data layer. I'd then write the service layer ontop of the data layer. nosql database API's are massively parallel (look at couchdb with its ngingx service layer parallizer). I'd then provide "oldschool each request is a web-page" generating web-servers and also direct access to the service layer for new style AJAX application; both these would depend on the service layer.

p.s. the RDBMS is an important component here, it holds the authoritative copy of the all the data in the memchached/nosql cloud. I would use an enterprise grade RDBMS to do data-centre to data-centre replication. I don't know how the big boys do their cloud based site replication, it would scare me if they did data-cloud to data-cloud replication :P

Some points:

• yYu do not need heartbeat, with nosql the approach taken is that if content becomes unavailable, you regenerate it onto another server using the authoratitve copy of the data.
• The burden of state-less web-design is carried to the nosql and memcached layer which is infinitely scalable. So you do not need to worry about this. Just have a good network infrastructure.
• In terms of sync, when you are talking to the RDBMS you can expect acceptable synchronous response times. Your cloud you should treat as an asynchronous resource, you will get help from the API's that interface with your cloud so you don't even have to think about this.
• Advice I can give about networking and redundancy is this: do not go for fancy Ethernet bonding, as its not worth it -- things always go wrong. Just set up redundant switches, ethernet cards and have multiple routes to all your machines. You can use OpenBSD and CARP for your routers, as they work great - routers are your worst point of failure -- openbsd solves this problem.

2. You've described the general components of a web 2.0 farm, so no comment:D

Answer 2

I think that, in the real world, high-availability systems are implemented using fail-over: for example, it isn't that the UI can continue to work without the business layer, instead it's that if the business layer becomes unavailable then the UI fails over to using a backup instance of the business layer.

Apart from that, they might operate using store-and-forward: e.g. a mail system might store a piece of mail, and retransmit it periodically, if it can't deliver it immediately.