I worked with many architectural styles, but the one which took most of my attention is the distributed node architecture. With that you can create really high scalable systems using a queue and applications instances which consumes it and process transactions.
Basically what you need is: On the front-side of you application you need to create specific transactional objects which will be processed by the instance nodes. For instance, you have a Create User use case which the main functionality is to save the user to the database and send an e-mail to the client to activate his account.
If you think in the distributed style, all you would need is a consumer to a queue which processes the transactions, process it and put back to another queue the response. Imagine you have 3 nodes of this application running; each one can consume a transaction per second, which would make it very fast and reliable.
All these events in this architecture are asynchronous. To give a better explanation on this, the steps is as follow:
- Java Script client app creates a Web socket connection with a front server determined by the load balancer;
- Java Script client app creates a transactional object (e.g. Create User) with a unique UUID;
- Java Script App sends the transactional object to the server in a rest fashion;
- Front app process the request and validate it, if ok put to the MQ server (A);
- A random node in the server processor pool pick the transaction off the queue (A);
- Server app process the transaction, writing to the database, sending e-mails and all the business rules required;
- Server App creates and put the response transaction to the second queue (B)
- Front application nodes consumes the queue B and pick off the response transaction;
- Front app send the transactional response with its same UUID;
- Process is finished.
Examples of Available Queue Software In Java: Hazelcast (For distributed applications), Active MQ.
The objective of this post was just to introduce you this architecture which is one of my favorite ones when talking about large scale applications. Consider using mongo instead of a large scale database and hazelcast instead of a JMS compliant QUEUE.