Components Flashcards
DNS
What is it?
How does it relate to offerings from AWS, others?
What other functionality can DNS provide?
What downsides/risks are there?
Domain Name System that associates domain names e.g. www.example.com with IP addresses.
Companies can have their own DNS servers. AWS Route53 (blog) is just another authoritative DNS service, like GoDaddy. “Authoritative” means this is where public requests go to find IP addresses.
ELB: You can direct a host name to the IP address of an ELB.
EC2: You can direct a host name to the public IP of an EC2 instance.
S3: You can have a CNAME to redirect a host name to .s3..amazonaws.com
Route53 and other DNS services can provide load balancing as well, such as weighted round robin, latency-based or geo-based
- Weighted round robin: the DNS server assigns a weight to each address, and round robins proportionally. You can assign weight based on historical performance, A/B testing, etc.
- Latency-based: E.g. Route53 can store latency data for registered services against request source location (public DNS can pass along the request’s truncated IP which has location data). Next time that location makes a request, Route53 can choose the lower latency service.
DNS servers cache these mappings. DNS servers typically put a TTL on addresses. But they can still become stale due to propagation delays.
The client (browser, OS etc) can cache IP addresses to prevent future DNS lookups. This can skew round robin.
Instead of having the DNS server round-robin, you can have the DNS server just point to the load balancer, and the LB distributes to servers.
Every DNS record has 4 parts: the name (example.com), the type (A for IP4, AAAA for IP6, CNAME for redirect), the value (IP address), and the TTL in seconds.
“example.com : A : 182.124.4.12 : 60”
CDN (Content Delivery Network)
What is it?
What kind of content?
How does it work?
How does caching work?
Benefits? Risks?
A network of proxy servers that reduce latency by being geo-located to the client and caching static or dynamic content.
Static content includes anything that does not change based on the user, e.g. CSS, JS, images, video files, PDFs.
How does it work?
- CDN provider gives a url for the CDN network. The resource has a path within that url.
- Client sends request.
- Application server can return the CDN url (which will be cached by browser for future requests), OR
- load balancer can be smart to redirect request to CDN url based on subdomain or url path rules (e.g. images.example.com or example.com/video) OR
- DNS service itself e.g. Route53 can be configured to route to CDN e.g. Cloudfront
- CDN then fetches content from cache or bucket/app server/other.
Caching content: The CDN content may be populated by client requests (pull model) or by the application servers (push model). The request URL is often used as the cache key.
- Pull model is when there is a lot of data that can change often. User behavior determines cache content. This is default for AWS Cloudfront.
- Push model is when there is less data or data rarely changes. Application decides what is hosted.
- Application servers can decide with response headers: Content-Type response header (which NGINX, Apache etc set automatically), and on the Cache-Control header.
Sys design benefits:
- Reduce latency via geolocation
- High Availability by moving load off application servers
- Reliability by caching content in multiple locations
Risks/downsides:
- Cached content can go stale until TTL expires
- Security risks?
When you have relational data (Users -> Posts), the first solution is to use SQL for joins. (why…) What can you use in NoSQL for relational data?
- Cassandra (column DB) offers collections (sets, lists, maps). So a user ID can have a set of PostIDs that can be stored sorted and have fast retrieval/add/remove.
What is long polling?
Think of it as a ‘hanging GET’. The client opens a connection and leaves it open for a period of time, e.g. 10 seconds. Applications can fake a continuous connection by reopening this in a loop. Server will respond if it has anything.
Downsides: uses server resources maintaining these connections. Over a long period, it is receiving many requests for no purpose. It also consumes client battery by making it issue request after request. Also questions such as: How does load balancing work? If one of the servers goes down, what about failover?
TCP vs UDP
Which is Websockets
Which is WebRTC
TCP is a connection-oriented protocol, whereas UDP is a connectionless protocol.
The speed for TCP is slower while the speed of UDP is faster
TCP uses handshake protocol like SYN, SYN-ACK, ACK while UDP uses no handshake protocols
TCP does error checking and also makes error recovery, on the other hand, UDP performs error checking, but it discards erroneous packets.
TCP has acknowledgment segments, but UDP does not have any acknowledgment segment.
TCP is heavy-weight, and UDP is lightweight.
TCP: World Wide Web(HTTP) E-mail (SMTP TCP) File Transfer Protocol (FTP) Secure Shell (SSH)
UDP: Domain Name System (DNS) Streaming media applications such as movies Online multiplayer games Voice over IP (VoIP) Trivial File Transfer Protocol (TFTP)
Websockets: A two-way TCP connection. It is initiated by an HTTP request with an “Upgrade” header. Intermittent polling detects if the connection is working or needs to be refreshed.
Downsides: you have to maintain this connection, which may not be best for one-off polling that is infrequently initiated by the client. But overall it sounds far better than long-polling.
WebRTC: UDP-based
Push Notifications (iPhone, Android)
It sounds like companies with notifications send them to Apple/Google, who then push them to the device.
It also seems like the device and Apple/Google server maintain a websocket-style connection for all these notifications, which is battery-efficient.
Push Services (I think this is different from Push notifications)
There are multiple 3rd party services (e.g. OneSignal) that provide APIs to send push notifications to multiple devices (phone, browser, email, etc). How Push works. They all subscribe to a common Push API. They can queue up messages to be sent when the client device is online.
Ultimately the message is delivered to a Service Worker in the device browser (Firefox, Chrome, etc). I think this is all made possible because the client device agrees to ‘subscribe’ to your service, and then you and the Push Service share a key.
Managing Sessions
“If I have an LB and multiple servers, how do I handle session state? If a user’s request is routed to a different server each time, each server needs to see the same state to provide a consistent experience.”
You can either have shared session storage (replication), or tie users to particular servers (sticky sessions). There are also alternatives such as “stateless authentication” using something like JWT.
Shared sessions: Servers use shared db or shared cache. Shared cache is more common.
“Sticky sessions” is also called session persistence.
- All client requests are routed to the same server. There are several ways to do this. E.g. the LB can add its own cookie to the response. It uses this cookie in future requests to map to the server address.
Risk 1: if that server goes down, session state is lost unless you also have some session replication.
Risk 2: to use the cookie, the LB would need to decrypt the request and read it - security concern and affect performance
Stateless auth with JWT: you can save session state in the encrypted token.
Claim-Based Identity
Claim-based identity is a component within the Single Sign-On (SSO) framework. ‘Claims’ of what a user’s ‘identity’ are provided by an ‘issuer’, typically within a ‘security token’. The receiver of the token only has to trust the issuer. The token is typically encrypted.
SAML
Security Assertion Markup Language, an open standard for authentication between a Service Provider and Identity Provider for a Principal / User Agent / Human. It was released in 2001.
Important use case for SAML is SSO. It relies heavily on HTTP.
What it looks like:
The service provider redirects the user to the SSO for the Identity Provider:
`https://idp.example.org/SAML2/SSO/Redirect?SAMLRequest=request
The “request” param is the SAML auth request (XML form) encoded in Base64.
The Identity Provider responds with a XHTML POST form that is also encoded. The user then posts this to the Service Provider which has an endpoint available to handle this format. The Service Provider processes it, creates a security context for the user, and redirects them to their final destination.
JWT
JWT = JSON Web Token
A standard within claim-based identity that is designed for use within browser-based SSO between an identity provider and service provider. It relies on other standards JWS and JWE.
Blink had an integration with a 3rd-party. Customers with existing Blink accounts could purchase a doctor consultation. They would then be redirected to the 3rd-party for their consultation.
To prevent them having to sign in or create an account with the 3rd-party, we created an encrypted JWT token.
It was put in an auth header in API requests to the 3rd party, and added it as a param in the URL when we redirected the user from Blink to the 3rd-party.
This token included: user account information, the Blink account id hashed so that we had a 1:1 connection with the 3rd party’s account record, a css stylesheet for the ‘white-label’ experience on the 3rd party, and a ‘return URL’ where the 3rd party should redirect the user back to Blink after the consultation was complete. The token had an expiration of 1 hour.
The token had a signature using a shared secret key (and HMAC?), and then encrypted with our secret key
.
As long as the 3rd party service provider can decrypt the message and then build the same signature with the shared key, they can trust it.
Service Discovery
In Microservices, you want a directory service like Consul, Etcd, Zookeeper to help keep track of registered names, addresses, ports.
They provide a DNS-style interface to provide IP addresses.
I believe that Kubernetes (and EKS) provide this as well with a dedicated DNS pod/service on the cluster. All service containers request this DNS pod to resolve names -> IP addresses.
Health Checks
Typically, an HTTP request to ensure a service is up and running.
