This is a case study about an enterprise solution POC (proof of concept) Isana Systems built where The Service creates a cryptographically authenticated End-to-End secure communication channel between the Enterprise digital assets and the customer endpoint over any digital channel. The service offers the Consumers of Enterprise Digital Services – a secondary factor authentication for accessing these Digital Services. For Enterprises to make their Digital Services available to the Consumers over secure communication channel, the Enterprise Services need to integrate with the Service.

The integration was expected to be done at following 2 levels:

* Web UI for Enterprise Digital Services

* Web Service exposing the Enterprise Digital Services

The Solution comprises below main software pieces:

• Core Web Service in Cloud which manages secondary factor authentication

• Different SDKs for the Consumers endpoints like Mobile (Android), Web along with mock-up applications

• Different platform specific libraries for the Enterprises to consume web-service API

• UI for Enterprise on-boarding, management and reports

Importantly being the core SaaS web-service, which is serving multiple Enterprises & their consumers, mainly in financial sector, the solution POC expected to have below main qualities:

• Concrete security, internal & external both sides

• Performance; One node setup was expected to handle ~1000 requests per second

• Scalable architecture supporting both vertical and horizontal scale-up

• Smooth Web UI along with dashboard reports

Often it is a big challenge to accomplish such deliverables within a short span of time with expected outcome. Isana Systems on-boarded to build this product within a quarter duration with a half-dozen engineer (Architect, Developers and Quality Analyzers).

Post understanding of the problem statement, we first accomplished component communication and architectural diagrams along with sequence diagrams for individual use cases. As well documented database schema & Web Service REST APIs. This is a minimum list of documentation you need to start with and that helped us moving on fast track.

Below picture gives architectural overview for this project.

Here are few key aspects of this product development which enabled us to deliver a robust product with a lot more caliber & quality than expected in POC phase.

• Quality Open-Source software usage:

• • Leveraged Quality Open-Source software like, Jersey for web-service REST API implementation, MongoDB for document based Scalable database, Jongo library for async database communication, greenDAO for Android application ORM layer, Nginx for load balancing and reverse proxy purpose and few other libraries.

  • MongoDB is a JSON-style data store and is almost schema-less. The documents stored in the database can have varying sets of fields, with different types for each field. This document-oriented database helps doing quicker development

• Software Re-use – Platform specific Generic Utils

  • Isana Systems keeps developing useful generic libraries and utils inhouse which helps to speed up product foundation building. Localization enabled platform specific Error Handler, logger, authentication & session management wrapper libraries using JWT, REST API input integrity validator, wrapper libs for different Message Queues integration, Generic libraries for UI graphs/reports are few of them to list down

• Design Patterns & Plugin Architecture

  • Core services Architecture uses various design patterns forming pluggable architecture. For instance, the above architecture uses MongoDB as backend database and in future for certain reason if it needs to be migrated to Cassandra then it shall be trivial exercise without impacting to core algorithm. This can be achieved by leveraging database independent DAO layer. Another example would be management of request contexts which web-service uses to store input data, update during processing and uses for response. For one node POC preparation, we went with in-memory context but using pluggable design it enables to easily introduce say, Apache Kafka based message queue which can service contexts to a large cluster of the core service.

  • Abstract Factory, Builder, Strategy, State, Singleton are often used design patterns to make a neat, maintainable architecture. With that, individual request processors or new REST APIs can also be added even at the application run-time.

• Performance Aspect.

  • All the implemented modules follow non-blocking i/o while communicating with other components. Like, back-end service talks to MongoDB database using Jongo open-source DAO which does nonblocking i/o calls. It helps keeping down overall thread count and making process performant.

  • As REST API call handlers too are non-blocking using Jersey framework, it helps keeping down Tomcat application server thread-count. In Tomcat default max thread-count is 200 where non-blocking mechanism brings it way down to logically max number of CPU threads on the server. We used 16 Tomcat thread-count serving 300+ concurrent network connections. Due to less thread count frequent context switching is avoided and overall results into greater Performance.

  • UI design too whether it is Android application or web-app based on Angular or React, follows MVC architecture keeping UI thread nonblocking so user sees smooth UI experience while data being fetched from back-end.

• Security Aspect

  • Only SSL/HTTPs based back-end communication permitted; secure database connection; all passwords used by core service are encrypted; REST APIs validates JWT based auth-token; Auth-tokens are encrypted nonce which keeps changing periodically; integrity hashing to verify input data; no files giving access to non-root user; SSL pinning support; DDos attack prevention at Nginx gateway are some standards followed to keep up the security for this project.

• Scalability Aspect

  • Stateless back-end service; auto-scalable, auto-failover supported document-oriented performant database like MongoDB; design support for easy migration to any message brokers like Apache Kafka or RabbitMQ; as well as Nginx based load-balancer provision in front of back-end nodes makes the architecture scalable from the POC time itself

  • Validity phase identified that the one node system is capable of handling 7000 requests per second with each request average response time was between 300 to 500 Ms. The result was more than 6000 requests per second total maximum load expectation.

© 2018 Isana Systems