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 1 client application 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 2 the signzy suite 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 3 signzy hosted services 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 4 other services client's native crm, verification services, and core banking systems connectivity with any third party systems and regulatory apis 5 inbound integrations enables other systems from the client and their vendors to integrate with the signzy system (examples lms and crm systems) network architecture 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 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 help\@signzy com