AWS Load Balancer Architecture

AWS Load Balancer is a highly available and scalable service that distributes incoming traffic to multiple targets (such as EC2 instances, containers, and IP addresses) across one or more Availability Zones (AZs) within a region.

This helps to improve the availability, scalability, and fault tolerance of your applications by ensuring that incoming traffic is evenly distributed and that healthy targets receive traffic.

Here's an example of AWS Load Balancer architecture using an Application Load Balancer (ALB):

Example

In this example, the web application consists of two microservices running on different EC2 instances within two Availability Zones.

The ALB is used to route incoming HTTP/HTTPS requests to the appropriate microservice based on the path of the request.

The architecture consists of the following components:

1. Clients: These are the users who access the web application via a web browser or a mobile app.
2. DNS: The domain name system (DNS) routes incoming requests to the appropriate load balancer based on the domain name.
3. Application Load Balancer: The ALB routes incoming requests to the appropriate microservice based on the path, host, query string, or headers of the request.
4. Target Group: A target group is a collection of targets (such as EC2 instances or containers) that receive traffic from the load balancer based on the configured routing rules.
5. EC2 Instances: The EC2 instances host the microservices that handle incoming requests from the ALB. These instances are registered with the target group and receive traffic based on the routing rules.
6. Availability Zone: An Availability Zone is an isolated location within a region that consists of one or more data centers. The targets are distributed across multiple Availability Zones to improve fault tolerance and scalability.
7. Auto Scaling Group: An Auto Scaling group is used to automatically scale the number of EC2 instances based on the demand to handle incoming traffic.

Overall, the AWS Load Balancer architecture helps to ensure that incoming traffic is evenly distributed across multiple targets, resulting in improved availability, scalability, and fault tolerance.

Teradata architecture

Teradata Architecture:

Teradata mainly contains the following architectural components.
1. Parsing Engine (PE)
2. BYNET
3. AMP (Access module processor)
4. Disks

Parsing Engine:
Parsing Engine is a virtual processor (vproc).It has the following software components.
1. Session control
2. Parser
3. Optimiser
4. Dispatcher

 Whenever a SQL request is given to the parsing engine the session control verifies for the session authorisation (user name and password) and based on that processes or will reject the request.

 Parser verifies the sql request for proper syntax and evaluates them. Checks the data dictionary if all the objects exist and if the user has authority to access them.

 Optimiser develops the least expensive (time) plan to execute the request .optimiser must know about system configuration, available AMP’S and PE’S. Optimiser enables Teradata to handle complex queries efficiently.

 Dispatcher controls the sequence in which steps are executed an passes the steps to the BYNET. BYNET is a messaging layer in between parsing engine and access module processor. After the AMPs process the steps, the PE receives their responses over the BYNET. The Dispatcher builds a response message and sends the message back to the user.

 Teradata uses hashing algorithm to distribute rows evenly across the amps .Based on the index column Teradata generates the hash value and based on that value data is sent to different amps. Data having same hash value will be sent to one amp (duplicate data).so depending on hash value data is evenly distributed across all the amps. when index is not selected properly data will not be distributed equally and hence leads to more data in one amp and less in one amp which is called skewness .