Architecture
Product architecture is a way to organize the functional elements of a product so they interact well. It also influences the design, manufacturing, selling, and use of a new product offering.
The system architecture designed by our technical team is critical for ensuring that our product is scalable, maintainable, and adaptable to future changes.
The client systems consist of client-side devices used by end-users, as well as the RM/SO and Ops teams. These devices typically run web applications, mobile web apps, or mobile apps.
It hosts the infrastructure and Application Stack on the cloud/on-premise.
- 3-Tier Architecture: Web Layer, Application Layer, and Database Layer. Segmented through VLAN sub-netting.
- Outbound Connector: NAT Gateway integrated on private sub-nets (Application and Database Layer) for the outbound connection to various Services such as Client’s Native Services, Signzy’s AI APIs & other Government or Regulatory systems.
- Web Layer: Responsible for serving the Front-end code and reverse-proxying the traffic to various back-end services present in the application layer.
- App Orchestration:
- Kubernetes allows you to define and manage the various components of your application, including pods, services, and deployments, in a declarative manner. This makes it easy to deploy and manage containerized applications across multiple nodes or clusters.
- Node scaling is an essential part of app orchestration, as it allows us to dynamically allocate resources to our application based on demand. By automatically scaling up or down the number of nodes that are used to run an application, we can ensure that it performs well under heavy load and can handle sudden spikes in traffic. This is also handled by Kubernetes.
- Clustered Databases:
- Stores the onboarding & verification data for each End User
- Data stored over replica set for high data availability, scalability & fault tolerance
- “Active/Passive” (Master/Slave) replication between DC & DR can be enabled
- Signzy Video Engine API to get the video bridge for RE & End Customer.
- AI capabilities and connectivity to different data sources.
- Uses an onboarding Engine to orchestrate the User’s flow according to the Client’s specific requirements.
- The utilization of other Signzy capabilities through Signzy’s API Gateway.
- Client's native CRM, verification services, and core banking systems.
- Connectivity with any third-party systems and regulatory APIs.
Enables other systems from the client and their vendors to integrate with the Signzy system (examples: LMS and CRM systems)
- Signzy is offering two types of journeys, namely the Web Journey (also known as the DIY Journey) and the RM Assisted Journey (which is available on the Mobile APK).
- Regardless of which journey is chosen, the request is first directed to the Traffic Manager, which then forwards it to the Application Gateway.
- The Application Gateway then separates the request based on the subdomain, handles the SSL termination, and balances the load between the Web Servers.
- The request is then forwarded to the Web Server, which is hosted by Nginx. Once Nginx receives the request, it sends it to the backend services on the backend servers via reverse proxy.
- The backend services handle the processing of the request and send the result back to the Web Server, which then serves the request.
The data collected during the journey is saved in the Databases. Any object type of data is stored in the Mongo DB, while any files, PDFs, images, and videos are stored in the Hot Tier Storage-Account/S3/NAS, and their references are stored in SQL/RDS/Oracle-SQL. Cache databases like RabbitMQ and Redis are used for the purpose of queuing.
The provided architecture diagram is a representation of a typical deployment in a cloud environment. However, it's important to recognize that the specific cloud platform chosen by a customer can affect the architecture of their system. This is because each cloud service provider offers different services and can have varying ways of implementing certain features. As a result, the architecture diagram provided is just an example of what a deployment could look like, and it may need to be customized based on the customer's specific cloud environment.
Moreover, if a customer decides to use an on-premise infrastructure instead of a cloud platform, the Kubernetes cluster in the diagram would not be applicable. In this case, physical or virtual machines would be utilized instead to manage the containerized applications. This is because Kubernetes is a platform that is typically used to manage containerized applications in a cloud environment. However, in an on-premise deployment, other container orchestration tools could be used, or the management of containers could be done manually through virtual machines.
In summary, the provided architecture diagram is only an example, and the actual architecture of a system will depend on the customer's specific requirements, cloud platform, and deployment environment.
Getting Help
If you have any questions, need clarification, or have suggestions to enhance our documentation or services, please don't hesitate to contact us.
Reach out to us at [email protected]