This week’s system design refresher:
8 Most Important System Design Concepts You Should Know (Youtube Video)
DNS Record Types You Should Know
Polling Vs Webhooks
API Vs SDK!
How Netflix Really Uses Java?
Big O Notation 101: The Secret to Writing Efficient Algorithms
The Ultimate Kubernetes Command Cheatsheet
SPONSOR US
Here are the 8 most commonly used DNS Record Types.
A (Address) Record
Maps a domain name to an IPv4 address. It is one of the most essential records for translating human-readable domain names into IP addresses.
CNAME (Canonical Name) Record
Used to alias one domain name to another. Often used for subdomains, pointing them to the main domain while keeping the actual domain name hidden.
AAAA Record
Similar to an A record but maps a domain name to an IPv6 address. They are used for websites and services that support the IPv6 protocol.
PTR Record
Provides reverse DNS lookup, mapping an IP address back to a domain name. It is commonly used in verifying the authenticity of a server.
MX Record
Directs email traffic to the correct mail server.
NS (Name Server) Record
Specifies the authoritative DNS servers for the domain. These records help direct queries to the correct DNS servers for further lookups.
SRV (Service) Record
SRV record specifies a host and port for specific services such as VoIP. They are used in conjunction with A records.
TXT (Text) Record
Allows the administrator to add human-readable text to the DNS records. It is used to include verification records, like SPF, for email security.
Over to you: Which other DNS Record Type have you seen?
Polling
Polling involves repeatedly checking the external service or endpoint at fixed intervals to retrieve updated information.
It’s like constantly asking, “Do you have something new for me?” even where there might not be any update.
This approach is resource-intensive and inefficient.
Also, you get updates only when you ask for it, thereby missing any real-time information.
However, developers have more control over when and how the data is fetched.
Webhooks
Webhooks are like having a built-in notification system.
You don’t continuously ask for information.
Instead you create an endpoint in your application server and provide it as a callback to the external service (such as a payment processor or a shipping vendor)
Every time something interesting happens, the external service calls the endpoint and provides the information.
This makes webhooks ideal for dealing with real-time updates because data is pushed to your application as soon as it’s available.
So, when to use Polling or Webhook?
Polling is a solid option when there is some infrastructural limitation that prevents the use of webhooks. Also, with webhooks there is a risk of missed notifications due to network issues, hence proper retry mechanisms are needed.
Webhooks are recommended for applications that need instant data delivery. Also, webhooks are efficient in terms of resource utilization especially in high throughput environments.
API (Application Programming Interface) and SDK (Software Development Kit) are essential tools in the software development world, but they serve distinct purposes:
API:
An API is a set of rules and protocols that allows different software applications and services to communicate with each other.
It defines how software components should interact.
Facilitates data exchange and functionality access between software components.
Typically consists of endpoints, requests, and responses.
SDK:
An SDK is a comprehensive package of tools, libraries, sample code, and documentation that assists developers in building applications for a particular platform, framework, or hardware.
Offers higher-level abstractions, simplifying development for a specific platform.
Tailored to specific platforms or frameworks, ensuring compatibility and optimal performance on that platform.
Offer access to advanced features and capabilities specific to the platform, which might be otherwise challenging to implement from scratch.
The choice between APIs and SDKs depends on the development goals and requirements of the project.
Over to you:
Which do you find yourself gravitating towards – APIs or SDKs – Every implementation has a unique story to tell. What's yours?
Netflix is predominantly a Java shop.
Every backend application (including internal apps, streaming, and movie production apps) at Netflix is a Java application.
However, the Java stack is not static and has gone through multiple iterations over the years.
Here are the details of those iterations:
API Gateway
Netflix follows a microservices architecture. Every piece of functionality and data is owned by a microservice built using Java (initially version 8)
BFFs with Groovy & RxJava
Using a single gateway for multiple clients was a problem for Netflix because each client (such as TV, mobile apps, or web browser) had subtle differences.
To handle this, Netflix used the Backend-for-Frontend (BFF) pattern. Zuul was moved to the role of a proxy
GraphQL Federation
The Groovy and RxJava approach required more work from the UI developers in creating the Groovy scripts. Also, reactive programming is generally hard.
Reference here