Architecture - saayam-for-all/docs GitHub Wiki

Following is the proposed architecture.

Saayam-flow-updated-Redis

We need to support 4 different clients:

  • Web application running from AWS S3 and CloudFront - Available in phase1
  • Mobile applications running on both iOS and Android - Available in phase2
  • Saayam API - Useful for integration with other volunteer organizations - Available in phase3
  • Saayam SDK - Programmatic integration with other organizations - Available in phase4

We are planning on running all our backend in AWS.

Overview:

“Saayam for all” aims to help people who make requests in different categories. Registered volunteers can pick up on the requests and work accordingly.

High level flow:

  • All client requests first go through CloudFront or Edge location that is closest to the consumer for faster performance.
  • Another main entry point would be Web Application Firewall (WAF) for security.
  • All requests will be sent to API Gateway.
  • API Gateway uses Cognito for authentication and authorization.
  • Authenticated requests will be sent to Lambda functions that act as publishers to MSK (Kafka).
  • MSK contains multiple topics based on functionality. For e.g. we can have one topic for CRUD operations of volunteers and another topic for CRUD operations of requests.
  • Lambda functions and micro services act as consumers of MSK. Based on complexity we can decide whether we should go with a lambda function or micro service.
  • All micro services run in EKS (Kubernetes)
  • Planning to use Aurora database (with or with out Postgres flavor - TBD) as our database.
  • For data analysis, we will store relevant information on S3 and then use tools like Glue, Athena and QuickSight etc for analysis.
  • Micro services can use ElastiCache for in memory cache.
  • We will be using many other AWS services like Route53 for DNS, CloudWatch for monitoring, SageMaker for data analysis, CloudTrail for auditing, X-Ray for tracing, Event Bridge for event handling, SNS for notifications, SQS for buffering etc.

Frontend (UI Layer):

Signup Page:

The signup page allows users to register with the system using the standard signup page or using Single Sign-on (SSO). Currently, the system supports Facebook and Google. The standard sign-up page contains the user’s First and Last names, Email, Phone number, Country, and Password. The Cognito will send an OTP for the registered phone number. This OTP can used to set the password for the account. Name, Email, and Phone number are utilized by the AWS Cognito – user pool to register the user into the system. The country is utilized to choose the database whether the user belongs to Europe or non-Europe. Email can exist in either one of the databases even though we may try to register the email with a different phone number. Registering the existing email id with a new phone number can be done by sending an email request to the administrator. (Enhancement. There is no page exists for this).

Login Page:

The login page allows users to logging in using a registered email id and password. Also, simultaneously it will allow you to logging in using Single Sign-on (SSO) credentials like Facebook and Google.

Error Handling: (Enhancement)

Must through the error label when

• Entering the wrong password or email.

• Missing password and/or email.

User Groups

Refer to the new user groups defined in our MVP - Requirements doc - https://github.com/saayam-for-all/docs/wiki/MVP-%E2%80%90-Requirements

Roles & Privileges

We use AWS IAM service to create necessary roles and privileges. These roles will be assigned to the above user groups. Resources stipulate what roles/privileges are needed to access them.

The principle of least privilege (PoLP) is an information security concept that limits users and applications to the minimum amount of access they need to perform their jobs. This can include access to data, resources, and applications.