A path-vector routing protocol is a network routing protocol which maintains the path information that gets updated dynamically. Updates that have looped through the network and returned to the same node are easily detected and discarded. This algorithm is sometimes used in Bellman–Ford routing algorithms to avoid "Count to Infinity" problems.
Well, this blog has nothing to do with that or neither about an ultimately more complex algorithm that we used to determine the components and its architecture.
Here we would like to share the team’s deep practical experience in what we are doing from an architectural perspective along with some of the conflicting needs we had to solve.
Cloud vs. On-Premise
The first principle we adopted was the understanding that the platform of the future would be Open X; and the belief that there would be specialized players with advanced and optimized skill sets; using them ensures we are always at the cutting edge of what is available.
Leveraging the capabilities of experts who adroitly manage hardware, infrastructure and data centers, gives us the freedom to focus on building the platform by:
- Using the domain expertise, we have to address the problem we are solving, and
- Empowering entrepreneurs in the Financial Advisory space.
Cloud Provider
One vital decision we had to make was which cloud provider is the best to go for our work. Amazon has a proven track record of continuously innovating and developing services that make application development easy. Hence, we chose AWS, primarily for being a one-stop shop for all the identified services we required. Many of these services are managed and are available as server-less with auto-provision and auto-scale features. AWS also provided services for the entire project life cycle from source control to development and deployment, improving the productivity of the developers.
Yes, there were other considerations too that we factored in like commercials, variability in costing as we scale and more.
Containers vs. FaaS
Fintso’s platform will be built as a set of micro services, which can be realized in multiple ways. We considered two options - Containers and FaaS (Function as a Service). The argument in favor of Containers was that it would allow us to be cloud-agnostic. We could move the entire setup to a different cloud provider whenever the need arose.
However, containers brought with them the need for orchestration engines and management. Developing just the services to be cloud-agnostic while leveraging a lot of AWS native services such as SQS, SNS, API Gateway, Elasticache, ELB, etc., wasn't really being cloud-agnostic.
Our other potent option was FaaS. AWS Lambda, while being a great alternative, comes with some limitations related to execution time and memory. For short-running processes, we decided to use Lambda. Fintso also has many long-running processes dealing with a large volume of data, hence we chose AWS Batch.
RDS vs. DynamoDB
Our initial study of RDS taught us that hosting PostGreSQL on AWS would require managing the EC2 instances behind the database and performing all DB related maintenance activities.
DynamoDB is a fully managed wide-column NoSQLDBaaS and comes with scaling, sharing, replication, etc. for large volumes of data. Having previously worked on DynamoDB and modeled relational data to be stored in a DynamoDB table, we were leaning towards using it as a primary data source at Fintso. We would certainly be using more than one table with each table containing logically connected entities.
We started designing the subscriber plan-service-subscriber-user-role entities as a single table in DynamoDB. We realized that with sufficient redundancy, data could be retrieved using the ID of any of the entities. However, we would face a big issue when one of the entities underwent a change and the same would reflect across various connected entities. This would involve multiple writes making maintenance of data integrity challenging.
Fintso deals with a lot of transactional data and many tightly coupled entities. We chose to use Aurora RDS with PostGreSQL for this purpose. For master data, historical data and reporting, we chose to use DynamoDB.
This is a prominent architectural part of the Platform:
To be continued …..
These are some tech-based decisions we've had made so far. Fintso is developing and transforming, as we progress to solve more issues faced by advisors. We believe we have a “beginner’s mind” and many critical decisions to make as we continue on our journey to bring you the ultimate Digital Wealth Management solutions.
As the platform continues to evolve, we will continue to share the story of our inspiring journey and the decisions we take.
By Shilpa Nagavara, Solutions Architect & Full Stack Developer Lead, Fintso
Over 17 years, Shilpa has built applications for healthcare, federal, transportation and banking domains. She has designed systems using a wide array of diverse technologies from Microsoft to Java to JS to PHP to now Python and AWS. She specialises in finding simple and robust solutions to complex problems by leveraging state-of-the-art technologies.
Find out more on our website or Shilpa's LinkedIn