Web Application & Software Architecture Flashcards
Definition of a Tier:
Logical and physical separation of components in an application or service.
Separation occurs at a component level, not the code level.
Components include database, backend server, user interface, messaging, caching, etc.
Purpose of Tiers:
To structure and organize an application’s components.
Enable scalability, maintainability, and flexibility.
Facilitate easier management and upgrades.
Determining Tiers in an Application:
Factors: Complexity, scalability needs, performance requirements, business logic.
No one-size-fits-all approach; depends on the application’s specific needs.
Types of Tiers and Examples:
Presentation Tier:
Responsible for user interaction.
Example: User Interface (UI) components like web browsers, mobile apps.
Application Tier (Middle Tier):
Contains business logic and processes requests from the presentation tier.
Example: Backend application servers, application logic components.
Data Tier:
Handles data storage and management.
Example: Databases (SQL, NoSQL), data storage systems.
Infrastructure Tier:
Supports the application by providing resources.
Example: Servers, networking infrastructure, cloud services.
Single-tier applications
In a single-tier application, the user interface, backend business logic, and the database reside in the same machine.
Single-Tier Applications -Upsides
No Network Latency: Components on the same machine, enhancing performance.
Immediate Data Availability: All components accessible on the local machine.
Data Privacy: User data stays on their machine, enhancing privacy and safety.
Performance Dependency:
Relies on the machine’s hardware and capabilities.
Single-Tier Applications -Downsides
Limited Control Over Updates: Publishers can’t update code/features post-shipment without manual user intervention.
Vulnerability to Buggy Code: No post-shipment updates could lead to user dissatisfaction.
Security Vulnerabilities: Source code exposure allows tweaking, reverse engineering, and potential security risks.
Inconsistent Performance/Look: Rendering varies based on user machine configuration.
Two-Tier Structure:
Client: Contains user interface and business logic on one machine.
Server: Hosts the database on a separate machine controlled by the business.
Need for Two-Tier Applications:
Reduced Network Calls: Locally hosted business logic minimizes backend server requests, lowering latency.
Use Cases: Suited for applications where security risks are minimal (e.g., to-do lists, productivity apps, games).
Examples:
To-Do List App: Backend calls triggered only upon data persistence.
Browser/Mobile Games: Heavy game files downloaded once, with minimal backend calls for game state persistence.
Cost Efficiency:
Fewer server calls lead to cost savings in server maintenance.
Choice of tier depends on business requirements and use cases.
Consideration for Future Tiers:
Design flexibility allows migration to three-tier architecture as per evolving business needs.
Three-Tier Applications
User Interface: Composed of HTML, JavaScript, CSS on one machine.
Business Logic: Runs on a server (e.g., Apache) on a separate machine.
Database: Stored separately, e.g., MySQL, on another machine.
Use Cases:
Popular on the Web: Commonly used for simple websites like blogs, news websites, etc.
Physical Separation: Components reside on different machines, creating distinct tiers.
Example:
Simple Blog: UI written in HTML, JavaScript, CSS; backend logic on Apache; MySQL for the database.
Benefits:
Structure and Separation: Organized division of UI, logic, and database.
Scalability and Maintenance: Allows scalability and easier maintenance.
N-tier applications
Components in N-Tier Applications:
Cache
Message Queues (Asynchronous Behavior)
Load Balancers
Search Servers (Handling Massive Data)
Components for Processing Massive Data
Heterogeneous Tech (Web Services, Microservices)
Examples of N-Tier Applications:
Social Applications: Instagram, Facebook, TikTok
Consumer Services: Uber, Airbnb
Massive Multiplayer Games: Pokémon Go, Roblox
Need for Multiple Tiers:
Single Responsibility Principle:
Dedicated Responsibilities: Components handle specific tasks flawlessly.
Flexibility and Management: Easier management, cleaner code, dedicated teams.
Loose Coupling: Changes in one component don’t impact others, enhancing robustness.
Stored Procedures Concerns:
Database Logic: Advocates against storing business logic in databases for future flexibility.
Separation of Concerns:
Reusability: Loosely coupled components enable reuse across services.
Scalability: Enables easy scaling of services as they grow.
Layers vs. Tiers:
Layers: Conceptual/logical organization of code (UI, business logic, data access).
Tiers: Physical separation of components across machines.
Difference Clarification:
Layers: Code-level organization.
Tiers: Physical separation of components.
Web App Architecture
Web Application Components:
1. Database
2. Message Queue
3. Cache
4. User Interface
Client-Server Architecture
Fundamental Web Building Block:
Request-Response Model: Client sends requests, server responds.
Ubiquity in Web Applications:
Usage in Websites and Apps: WordPress blogs, Facebook, Twitter, banking apps.
Rare Usage of Peer-to-Peer Architecture: A small percentage in business websites and apps.
Client
Role of the Client:
Holds User Interface: Presentation aspect of the application.
Responsible for Look and Feel: Composed of HTML, JavaScript, CSS.
Client Platforms:
Variety of Devices: Mobile apps, desktops, tablets (e.g., iPad), web-based consoles.
Gateway to the Application: Interface for interaction with the backend.
Technologies for Client-Side:
**Popular Libraries: **Vanilla JavaScript, jQuery, React, Angular, Vue, Svelte.
JavaScript Foundation: Majority of these libraries are JavaScript-based.
Platform-Specific Frameworks:
Diversity Based on Platform: Different tools for Android, Apple, Windows OS.
Platform-Specific Requirements: Tailored frameworks for distinct platforms.
Thin & Thick client
A thin client is a client that holds just the user interface of the application. It contains no business logic of any sort. For every action, the client sends a request to the backend server, just like in a three-tier application.
A thick client holds all or some part of the business logic. These are the two-tier applications.
The typical examples of fat clients are utility apps, online games, and so on.
Web Server
Role of a Web Server:
Receiving and Responding: Receives client requests, executes business logic, and provides responses.
Foundation for Online Services: Crucial for running online services.
Types of Servers:
Application Servers: Common servers for running web applications.
Other Servers: Proxy, Mail, File, Virtual, Data Storage, Batch Job Servers, etc.
Varied Configuration Based on Use Case: Specific servers chosen based on requirements (e.g., Apache Tomcat, Apache HTTP Server).
Focus on Application Servers:
Central for Web Application Components: Database, message queue, cache, user interface, etc., require servers to function.
Dedicated Hosting: UI components hosted separately on dedicated servers.
Server-Side Rendering:
Rendering Technique: Backend rendering of UI, sending generated data to the client.
Pros and Cons with Client-Side Rendering: To be discussed in upcoming lessons.
REST API Architecture
Request-Response Model:
Client-Server Interaction: Client sends a request, server responds with data.
Dependence on Request for Response: No response without a preceding request.
HTTP Protocol:
Data Exchange Protocol: Entire communication over HTTP.
**Stateless Nature: **Processes executed independently without knowledge of past processes.
Protocol for Web Information Exchange: Defines web data transmission.
REST API and API Endpoints:
Foundation of Modern Web Communication: Clients interact with REST endpoints on the backend.
Upcoming Detailed Discussion: Rest API and API Endpoints in the next lesson.
Real-World REST API Example:
Birthday Tracking Application: Fetches Facebook friend birthdays via the Facebook Social Graph REST-API.
Reminder Implementation: Runs business logic based on fetched data.
Benefits of REST-Based APIs:
Advantages to Explore: Detailed exploration in the next lesson for deeper understanding.
API Gateway
REST API Architecture
Follows REST Constraints: Implementation aligns with REST architectural principles.
HTTP-Based Communication: Interaction occurs over HTTP, leveraging HTTP methodologies.
Caching Benefits: Enables server-side caching for improved performance.
Stateless Communication:
Every Interaction is Stateless: No memory or information retained between client-server interactions.
Authentication with Each Interaction: Client provides authentication info in each request.
Decoupling Backend and Clients:
REST Endpoint Definition: URL for services accessible to clients (e.g., https://myservice.com/users/{username}).
Decoupling Impact: Backend service independent of client implementation; endpoints shared for data access.
Benefits of Decoupling:
Flexibility in Client Implementations: Different clients (mobile, web, testing tools) accessing the same API without affecting backend functionality.
Historical Application Development: Contrast between tightly coupled backend-client code (e.g., JSP) and REST API-based decoupling.
Simplified Backend Development:
Post-REST Implementation: Backend agnostic to client types; standardized response format (e.g., JSON) for client-side handling.
Ease in Adding New Clients: Introduction of new clients without backend impact.
Pervasive Nature of REST APIs:
Industry Integration: Almost all online services utilize REST APIs for access to their data.
Role of REST-API as a Gateway:
Encapsulation of Logic: Handles client requests, manages authentication, authorization, input sanitization, etc.
Single Entry Point: Acts as the interface between clients and application resources.
HTTP Pull Mechanism
Default HTTP Communication Mode: Client requests data, server responds.
Client-Pulled Data: Fetches data from the server upon request.
Bandwidth and Server Load: Frequent requests consume bandwidth and stress server resources.
Issues with HTTP Pull:
Repetitive Requests: Continuously fetching data regardless of updates.
Resource Waste: Wastes bandwidth and may overload the server.
HTTP Push Mechanism:
Minimizing Client Requests: Initial request followed by server-initiated data updates.
Server-Pushed Updates: Server informs client of new data without additional requests.
Bandwidth and Server Load Reduction: Decreases network load and eases server burden.
Callback Concept:
Client’s Initial Request: Server promises to notify when new data is available.
Server-Based Notifications: Notifies clients upon available updates
Common Use Case:
User Notifications: Backend events triggering notifications to users.
AJAX in Both Mechanisms:
Asynchronous JavaScript & XML (AJAX): Used for client-server communication in both Pull and Push methods.
Technologies in HTTP Push:
Ajax Long Polling
Web Sockets
HTML5 Event Source
Message Queues
Streaming over HTTP
AJAX – Asynchronous JavaScript and XML
Asynchronous Behavior Addition: Enables asynchronous behavior on web pages.
Data Fetching Methods:
Manual HTTP GET Request: Triggered by user interface events (e.g., button clicks).
Dynamic Interval-Based Fetching: AJAX used to pull data at regular intervals without user intervention.
AJAX Functionality:
Automatic Server Requests: Sends requests automatically at set intervals.
Dynamic Page Updates: Updates specific webpage sections dynamically upon receiving updates.
Common Examples: Dynamic event display on news/sports websites without page reloads.
AJAX Implementation:
XMLHttpRequest Object: Utilized by AJAX to send server requests.
DOM Update: JavaScript manages HTML DOM updates.
AJAX and jQuery:
Common Framework Usage: AJAX often employed with the jQuery framework.
Polling with AJAX:
Dynamic Information Fetching: Technique known as polling via AJAX.
Regular Data Requests: Fetches data periodically from the server.
AJAX Polling vs. Long Polling:
Difference: AJAX Polling - HTTP Pull mechanism. AJAX Long Polling - Hybrid (HTTP Push-Pull).
HTTP Push
TTL in HTTP Pull:
Connection Lifespan: Time to Live (TTL) for each request in HTTP PULL.
Browser Behavior: Closes connection if no response within TTL; requires re-sending the request.
Purpose of TTL:
Resource Management: Controls open connections to prevent server overload.
Persistent Connection:
Definition: Continuous open network link for multiple requests and responses.
Contrast to Regular Connection: Doesn’t close after single communication.
Facilitating HTTP Push:
Role in Push-Based Communication: Enables sustained connection between client and server.
Heartbeat Interceptors:
Function: Blank request-responses to maintain open connections.
Preventing Connection Closure: Prevents browsers from terminating connections.
Resource Intensiveness:
Persistent Connection Resource Usage: Higher resource consumption compared to HTTP PULL.
Use Case Significance: Essential for certain applications requiring consistent connections (e.g., multiplayer games).
Techniques for Persistent Connections:
Examples: AJAX Long Polling, Web Sockets, Server-Sent Events.
Exploration in Upcoming Lesson: Detailed discussion on each method
Streaming over HTTP
Web Sockets:
Purpose: Bi-directional low latency data flow between client and server.
Use Cases: Messaging, chat applications, real-time social streams, browser-based multiplayer games.
Mechanism: Operates over TCP; requires mutual support by server and client.
AJAX Long Polling:
Functionality: Server holds response until update available; longer connection times than regular polling.
Benefits: Reduces client-server requests, conserves network bandwidth.
Server-Sent Events (SSE):
Approach: Server automatically pushes data to client as events.
Benefits: Reduces blank request-response cycles, conserves bandwidth.
Direction: One-way data flow: server to client.
Use Cases: Real-time feeds, notifications, stock quotes.
Streaming over HTTP:
Purpose: Breaks extensive data into smaller chunks for streaming over HTTP.
Use Cases: Multimedia content streaming (videos, images).
Functionality: Facilitates watching partially downloaded content in real-time.
Choosing Technology:
Considerations: Tech selection based on specific application requirements.
Tech Overview: AJAX for dynamic UI updates, Long Polling for asynchronous data, Web Sockets for bidirectional flow, SSE for server-to-client flow, HTTP streaming for large object transmission.
Server-Side Rendering (SSR)
Rendering technique where the UI is generated on the server and sent as HTML to the client.
Ideal for delivering static content like WordPress blogs.
Benefits SEO since search engine crawlers easily parse static content.
Reduces client-side rendering work, ensuring faster initial UI loading.
Client-Side Rendering (CSR)
UI rendering process occurs on the client browser using JavaScript after receiving raw data from the server.
Best suited for modern, dynamic, AJAX-based websites.
Allows on-the-fly content fetching and rendering, enhancing user experience.
Resource-intensive for server if used for entire page generation.
Use Cases for Rendering:
SSR: Static content-based websites, like blogs, where content rarely changes.
CSR: Modern web apps reliant on AJAX for dynamic content, requiring frequent updates without page reloads.
Hybrid Approach: Utilizes SSR for static sections and CSR for dynamic content, achieving a balance between speed and dynamic functionality.
Why does every browser request have a TTL Time To Live?
Because open connections between the client and the server are resource intensive and there is a limit to the number of open connections a server can manage.
When do we need to implement the HTTP PUSH mechanism in our application?
- When the application is a real-time application like an online multiplayer game, a LIVE sports app.
- When we need to reduce the number of client requests hitting the server every now and then, checking for new information.
Which HTTP PUSH based technology suits best for implementing a streaming media application?
Streaming Over HTTP
This technique is ideal for cases where we need to stream large data over HTTP by breaking it into smaller chunks. It is primarily used for streaming multimedia content, like large images, videos etc., over HTTP.
Which technique suits best for implementing a browser-based multiplayer game?
Web Sockets
Web Sockets facilitate bi-directional communication between the client and the server which is typically required in an online game.
When should we render the user interface on the server?
When the content to be rendered is static in nature.
Static content can be rendered on the server in comparatively less time as opposed to being rendered on the client. It can also be cached for future requests.
What is scalability?
Definition: Ability of an application to handle increased workload without compromising performance.
Ideal Scenario: Consistent response time for each user request, irrespective of the total number of concurrent requests.
Indicator: Maintaining system latency even under heavy traffic load signifies scalability.
Big-O Notation: Target complexity ideally O(1) for constant time; O(n^2) not scalable as data set increases.
Network latency
Definition: Time taken for the system to respond to a user request.
Key Components:
Network Latency: Time for data transmission between points A and B. CDN deployment minimizes network latency by leveraging edge locations.
Application Latency: Time for application to process user requests. Stress testing identifies bottlenecks.
Importance of Low Latency
User Experience: High latency leads to user frustration, impacting user retention and business revenue.
Industry Impact: Critical in sectors like gaming (MMOs demand real-time response), finance (low-latency trading), where even milliseconds matter.
Real-World Examples: Huawei spent millions to save traders six milliseconds by laying a fiber-optic link between London and New York.
Vertical scaling
Vertical scaling involves adding more power to a server, increasing its hardware capabilities like RAM, CPU, etc., to handle increased traffic.
Horizontal scaling
Latency
Latency is the time taken by a system to respond to a user request. It plays a crucial role in user experience, determining if users stay or leave a website.
Server-Side Rendering vs. Client-Side Rendering
Server-side rendering generates HTML on the server and sends it to the client, reducing initial load times. Client-side rendering renders pages in the browser, allowing for dynamic content.
Cloud Elasticity
Cloud elasticity refers to the ability to dynamically scale resources up or down based on demand. Cloud platforms provide scalability and cost efficiency for businesses.
Microservice Architecture
Vertical Scaling Pros
Simplicity: Adding resources to a single server is straightforward without complex configurations. Requires less administrative effort
Vertical Scaling Cons
Availability Risk: Few powerful servers might create a single point of failure. If one goes down, the entire system might face downtime.
Code Changes in Horizontal Scaling
Statelessness: In a distributed environment, code needs to be stateless to prevent data loss if a server goes down. Avoiding static instances and relying on distributed memory stores like Redis or Memcache.
Horizontal Scaling Pros
High Availability: Distributing workload among multiple servers ensures the system remains available even if one server fails. No single point of failure.
Horizontal Scaling Cons
Complexity: Setting up and managing a distributed environment requires more effort, monitoring, and system configurations compared to vertical scaling.
Choosing Scalability Approach
Predictable vs. Unpredictable Traffic: Vertical scaling works well for predictable traffic; single servers handle load. Horizontal scaling is suitable for unpredictable, high-traffic scenarios like social networks or online games.
Database Bottleneck
Single monolith database handling requests from multiple nodes can impact response time. Scaled database through partitioning, sharding needed.
Application Architecture
Poor design with sequential processing instead of asynchronous modules can bottleneck operations. Asynchronous tasks needed for uploads, notifications.
Caching Efficiency
Underutilizing caching layers affects response time. Caching helps intercept requests, reduces load, and lowers costs. Case study: PolyHaven’s effective use of caching.
Load Balancer Setup
Inefficient load balancer configuration impacts latency. Correct setup crucial for optimal application performance.
Business Logic in Database
Adding business logic in databases creates tight coupling, complicates migrations, and testing. Prefer separating business logic from the database layer.
Database Technology
Choosing unsuitable database tech affects application latency. Relational for strong consistency, NoSQL for horizontal scalability.
Code Level Efficiency
Poorly written code—nested loops, tight coupling, neglecting complexity—impacts production. DENTTAL checklist ensures code robustness.
Dashboard Monitoring Architectural Flow
Profiling for Bottlenecks
Utilize application and code profilers to identify resource-consuming processes. Address bottlenecks to enhance performance.
Caching Efficiency
Optimize caching strategies. Cache static content, limit database hits, and utilize write-through caching for enhanced performance.
CDN Implementation
Implement Content Delivery Network (CDN) to reduce latency by bringing data closer to users.
Data Compression
Apply compression algorithms to minimize data size and enhance download speeds, reducing bandwidth consumption.
Reducing Round Trips
Minimize unnecessary client-server round trips. Consolidate multiple requests to optimize performance.
Scalability Testing
Test system parameters like CPU usage, network bandwidth, throughput, latency, and user experience under heavy load to ensure smooth scalability.
Capacity Planning
Provision appropriate hardware and computational power based on scalability testing results to handle expected traffic with a buffer.
Load and Stress Testing
Run load and stress tests using tools like JMeter to simulate traffic and prepare for traffic surges during events or peak seasons.
High Availability (HA)
HA ensures system uptime despite infrastructural failures, improving reliability and minimizing downtime. Expressed as a percentage in SLAs.
Importance of HA
Critical for mission-critical systems like aircraft, hospitals, and finance. Vital for continual connectivity and functionality.
Fault Tolerance & Redundancy
Fault tolerance: Systems withstand failures. Redundancy: Duplication of critical components for backup, reducing the risk of system failure.
Highly Available Cluster
A cluster designed for high availability. Multiple interconnected servers ensure continuous operation, even if one fails.
Cloud Platform HA
Cloud platforms ensure HA by distributing services across multiple servers/locations, using redundant hardware and automated failover mechanisms.
common reasons for system failures:
Software Crashes:
Applications frequently crash due to various issues such as memory leaks, bugs, or corrupted files. Unresponsive processes or system crashes on devices are common occurrences.
Hardware Failures:
Hardware issues, including CPU overload, memory failures, hard disk crashes, or network outages, contribute significantly to system failures. A single node going down can disrupt the entire system.
Human Errors:
Mistakes in configurations, software deployment, or operational errors can cause system failures. Even minor errors can lead to significant outages, as seen in cases like network configuration issues causing widespread disruptions.
Planned Downtime:
Scheduled maintenance activities like software updates, hardware upgrades, or routine maintenance operations often require system downtime, impacting availability.
Fault Tolerance:
System Resilience: Fault-tolerant systems can endure faults without experiencing complete failure. They are designed to continue operating even if some parts of the system fail.
Redundancy and Failover: By employing redundant components or nodes, a fault-tolerant system ensures that if one fails, another can seamlessly take its place. This setup prevents system-wide disruptions.
Reduced Impact of Failures: Even if specific functionalities or services within a system encounter issues or go offline temporarily, the overall system remains functional.
Application-Level Fault Tolerance: Microservices architecture is a common approach to achieve fault tolerance at the application level. Breaking down a monolithic application into smaller, independent microservices enables resilience against failures in specific components.
Benefits of Microservices:
Improved Management: Easier management and maintenance of individual services rather than a monolithic application.
**Development Flexibility: **Enables easier feature addition and modification without affecting other services.
Scalability and Availability: Facilitates scalability and high availability by distributing functionalities across multiple services, ensuring that even if some services fail, others continue to function.
HA - Redundancy
Redundancy is duplicating the server instances and keeping them on standby to take over in case any of the active server instances go down. It is the fail-safe backup mechanism in the deployment infrastructure.
Redundancy and Active-Passive HA Mode:
Backup Mechanism: Redundancy involves having duplicate server instances on standby, ready to take over if active instances fail. This setup ensures fail-safe backup within the deployment infrastructure.
Active-Passive Mode: In this setup, an initial set of nodes are active and perform the primary functions, while a redundant set of nodes remain passive, only activated when active nodes encounter failure.
Eliminating Single Points of Failure: Redundancy eliminates single points of failure by distributing functionalities across multiple nodes. When one node fails, redundant nodes seamlessly take its place, ensuring the system continues functioning without disruption.
Advantages and Implementation:
Zero Downtime Systems: Critical systems like GPS, aircraft, and satellites rely on redundancy to ensure zero downtime, guaranteeing uninterrupted operation.
**Elimination of Bottlenecks: **Redundancy helps in overcoming bottlenecks by distributing workload across multiple instances, avoiding reliance on single components.
Real-time Monitoring and Automation: Continuous monitoring allows immediate detection of bottlenecks or failures, while automation enables self-recovery and dynamic scaling based on system requirements.
Reducing Human Error Impact: Automation significantly reduces the chances of system failures caused by human errors, improving system reliability and stability.
High Availability Clusters
Definition: A set of nodes working together to ensure continuous service availability.
Components: Nodes connected via a private network (heartbeat network), shared distributed memory, and coordination service (e.g., Zookeeper).
Techniques: Redundancy in disk mirroring (RAID), network connections, power sources to eliminate single points of failure.
Geographic Redundancy: Multiple clusters in a single zone for minimal downtime.
Importance: Crucial in maintaining uptime and ensuring service availability in software system design.
Load Balancing in Web Applications
Definition: Technique distributing incoming web traffic across multiple servers or resources.
Strategies: Round-robin, least connections, content-based routing, geographic-based routing.
Purpose: Optimizing resource utilization, ensuring responsiveness during high traffic.
Relation to Scalability/HA: Integral part of a robust system design for smooth user experience.
What is the need of a shared distributed memory in a high availability cluster?
To maintain a common state across several nodes running in a cluster.
Load balancing
Purpose: Enables scaling and ensures high availability during traffic spikes.
Function: Distributes heavy traffic across servers in a cluster using load balancers.
Risk Avoidance: Prevents overload on specific machines, averting latency spikes and performance degradation.
Failure Mitigation: Automatically redirects requests from failed servers to operational ones, ensuring overall service availability.
Single Point of Contact: Acts as the central entry point for client requests.
Granularity: Can manage traffic at various application component levels (backend servers, databases, message queues, etc.).
Health Checks: Regularly assesses server status to intelligently route requests only to operational machines.
In-Service and Out-of-Service Instances: Maintains a list of operational servers and redirects requests accordingly. Failed servers are temporarily removed and reinstated upon recovery.
Load Balancing At Different Components Of The Application
DNS
Understanding DNS:
IP Address vs. Domain Names: Every machine on the web has a unique IP address, but remembering and using IP addresses for every website is impractical.
IP and its Protocol: Internet Protocol (IP) is the system that enables data packet delivery between machines using their IP addresses.
DNS’s Role: Maps easy-to-recall domain names (like amazon.com) to their corresponding IP addresses.
Simplified Access: Users can type domain names into browsers instead of complex IP addresses for website access.
How DNS Works:
DNS Querying: Occurs when a user enters a website’s URL into a browser.
Key Components of DNS Infrastructure:
DNS Recursive Nameserver (Resolver): Interacts directly with the user’s browser, performs queries, and caches responses for future use.
Root Nameserver: Manages the root zone of the DNS, providing information about Top-Level Domain (TLD) nameservers.
Top-Level Domain (TLD) Nameserver: Handles TLDs (.com, .org, etc.), providing details about authoritative nameservers for specific domains.
Authoritative Nameserver: Holds specific domain information, providing IP addresses and other records associated with a domain.
DNS Query Lookup Process:
Involves a series of requests from the recursive resolver to the root server, then to the TLD server, and finally to the authoritative server for the specific domain.
Each server in the hierarchy helps resolve the domain name to its corresponding IP address.
DNS query lookup process works
Step 1: User Action
User types domain name in the browser and triggers a request.
Step 2: DNS Resolver (Recursive Nameserver)
Receives the request, forwards it to the Root Nameserver.
Managed by ISPs in optimized data centers.
Step 3: Root Nameserver
Responds with the Top-Level Domain (TLD) Nameserver address (e.g., .com for amazon.com).
Step 4: TLD Nameserver
Holds data for specific top-level domains.
Provides the IP address of the domain’s Authoritative Nameserver.
Step 5: Authoritative Nameserver
Manages the specific domain (e.g., amazon.com).
Returns the domain’s IP address to the Resolver.
Step 6: Resolver’s Action
Caches the retrieved data.
Step 7: Browser Interaction
Receives the IP address and requests website content from the domain’s server.
DNS Optimization and Caching:
Server Setup: ISPs manage efficient Resolvers in data centers.
Caching: DNS data is cached at different levels for faster retrieval.
TTL: Time to Live (TTL) dictates cached data validity.
Browser Cache: Modern browsers cache DNS info for quicker revisits.
DNS Load Balancing
Purpose: Distributes user traffic across multiple data centers or server clusters.
Implementation: Occurs at the DNS level on the authoritative server.
Large-Scale Services: Big services like amazon.com operate across multiple data centers globally.
How DNS Load Balancing Works:
Authoritative Server Role: Returns different IP addresses of a domain to clients upon queries.
IP List Generation: Provides a list of IP addresses in response, changing the order in a round-robin fashion for each query.
Client Response: Client sends requests to the first IP in the list; can use other IPs if the first doesn’t respond promptly.
Dynamic IP Ordering: Authoritative server rearranges the list order for subsequent requests using round-robin.
Load Balancer Impact:
Load Balancer Interaction: Requests might hit a load balancer managing application server clusters, not directly the server.
Limitations: Doesn’t consider server loads, content, processing time, or in-service status.
Caching Issues: Cached IPs might lead requests to out-of-service machines, impacting reliability.
DNS Laod Balancing Benefits and Drawbacks:
Advantages: Easy and cost-effective load balancing setup for companies.
Limitations: Doesn’t account for various server parameters, relying on simple round-robin distribution.
DNS load balancing, though straightforward and cost-effective, has limitations in its inability to consider server status or load. Despite this, it remains a popular choice for distributing traffic across multiple data centers in large-scale services.
Hardware-Based Load Balancing:
Physical Hardware: These load balancers are physical devices that distribute traffic based on various parameters like active connections and compute utilization.
**Performance and Maintenance: **They’re highly performant but require regular maintenance, updates, and specialized skills for upkeep.
**Expensive and Overprovisioning: **Costly to set up compared to software load balancers and need overprovisioning for handling peak traffic.
Software-Based Load Balancing:
**Installed on Commodity Hardware/VMs: **Runs on regular hardware or virtual machines, offering cost-effectiveness and greater flexibility for deployment.
Ease of Upgrade and Provisioning: Easier to upgrade and provision compared to hardware-based counterparts.
Advanced Features: Utilizes various parameters like server data, cookies, HTTP headers, and health checks for efficient traffic routing.
Popular Examples: HAProxy is a widely used software load balancer by major industry players due to its features and scalability.
Load Balancing Algorithms:
Round Robin and Weighted Round Robin: Sequentially sends IP addresses but with weighted distribution based on server capacity.
Least Connections: Routes traffic to servers with the fewest open connections, considering CPU utilization and request processing time.
Random: Randomly distributes traffic across similar servers.
Hash: Routes traffic based on hashed source IPs or URLs, ensuring consistency for client-server connections and efficient caching.
Why is DNS load balancing implemented on the authoritative nameserver?
Because the authoritative nameserver returns the IP addresses of a domain’s application servers. If we implement load balancing here, we can easily return different IP addresses of application servers on every client request.
Why does DNS load balancing make the authoritative nameserver return a list of IP addresses as opposed to just returning a single different IP every time?
This is done to enable the client to use other IP addresses in the list in case the first doesn’t return a response within a stipulated time.
Monolithic Architecture
Single Codebase: All components of the application reside within a single codebase, tightly coupled together.
Tightly Coupled Modules: Features like user posts, comments, marketplace, etc., are coded as part of one unit rather than separate services.
Simplicity in Development: Easier to build, test, and deploy compared to microservices architecture due to its unified structure.
Early Stage Preference: Often chosen during the early stages of a business due to simplicity and straightforwardness in development.
Trade-offs in Transition: Transitioning from a monolithic architecture to a distributed microservices architecture incurs significant costs in terms of time, effort, and resources.
Microservices Architecture
Decomposition of Features: Services are separated into smaller, independent modules, each responsible for a distinct feature or functionality.
Single Responsibility Principle: Each service has a singular responsibility, promoting a loosely coupled architecture.
Simpler Maintenance: Easier management, maintenance, and deployment due to smaller, focused modules compared to a monolithic architecture.
Team Efficiency: Facilitates the division of work among teams, allowing dedicated focus on specific modules or services.
Scalability: Scalability is inherent; services can be scaled independently without affecting others.
Database Separation: Each microservice ideally has its own database, reducing the risk of single points of failure and bottlenecks.
Segment high-level architecture
Segment Microservices architecture
Micro Frontend
Full Stack Teams With Micro Frontends
DB ARchitecture
Unstructured data
Distributed Data Processing
Distributed data processing involves dividing large data sets across multiple nodes in a cluster for parallel execution, enhancing scalability and availability while preventing data loss through redundancy.
What is the Lambda architecture in data processing?
The Lambda architecture is a distributed processing approach that combines batch and real-time streaming data processing to overcome latency issues inherent in batch processing.
What is Kappa architecture?
Kappa architecture employs a single data streaming pipeline, unlike Lambda architecture, simplifying data processing without distinct layers.
Event-driven architecture
What are web hooks ?
Webhooks are a mechanism enabling communication between services without middleware, functioning like callbacks where a service notifies another when specific events occur.
What are the three main components of the hexagonal architecture?
The three key components are Ports, Adapters, and Domain, aiming to create an independent, loosely coupled, and easily testable application structure.
How does hexagonal architecture differ from traditional layered architecture?
Hexagonal architecture is an evolved form of layered architecture, aiming to prevent scattering of business logic across multiple layers, unlike traditional layered approaches, which may result in complex, coupled codebases.
What does federated architecture entail in decentralized social networks?
Federated architecture extends the concept of decentralization, enabling interconnected servers or pods (like in Mastodon or Diaspora) to exchange information and maintain a network, akin to semi-autonomous entities sharing data.
For a mapping service with multiple features like route planning, real-time updates, and various APIs, which architecture—monolithic or microservice-oriented—would be better suited?
Microservice architecture is preferable to build separate services for various functionalities, ensuring scalability, maintainability, and high availability.
How are real-time features managed in a web-based mapping service, and what considerations should be made?
Real-time features require persistent connections and should be implemented judiciously due to their resource-intensive nature, considering limitations in handling concurrent connections on servers.
