The design making process for a complex application
- how would you build/design X?
- choose an application and walk through its components
- why do you think X framework was chosen over Y framework in this application?
- suppose we build system S, how would we handle X, Y, Z
- we want to design a service to perform X
- what are the use cases and who will use it?
- casual users or big corporate clients?
- data storage
- db style, data types, how long to store
- frontend
- collecting metrics
- exposing logs
- job queue
- cache data layer
- load balancer
- microservices
- read them
- standard internet communication protocol
- move data packets between Internet layer of 2 different hosts on same link
- usually physical connection
- exchange data through routing/IP addressing
- IP, ICMP, IGMP
- TCP, UDP
- HTTP, FTP, SMTP, …
- establish session through 3-way handshake
- 3 messages
- all packets guaranteed to reach destination in correct order without corruption
- packet control to control data transfer rate
- A initiates with B a. they exchange packets in a pattern like a cool handshake b. they begin TCP
- A sends packets to B with a sequence number and checksum for correct order + data integrity
- B acknowledges receipt of packets a. If B does not acknowledge a packet, A resends
- no session
- sends data from A to B, no verification
- hope for the best
- best for streaming
- send HTML
- client-response model
- call a function on a remote server
- just like a regular function call
- action based APIs/execute processes remotely
- tight coupling
- needs detailed documentation for usage
- resource based API
- stateless
- native caching
- idempotent
- multiple identical requests is same as single request
- loose coupling
- have many distributed CDN servers which store content closer to end users
- physical wires
- optic fibers
- caching
- compress files
- observe how users use app
- server speed
- high traffic will slow down website
- optimize and clean extraneous data
- allocate more memory to VMs that need it
- dependencies between different modules of an application
- how much do they rely on one another
- how closely related are elements of a single module
- where the entire system has to be deployed at once
- usually 1 server, 1 db, 1 file system
- easy to scale
- simple to develop/test
- easy to deploy
- low maintainability
- high coupling
- changes in one place will affect another place
- one error means entire system is down
- low design flexibility
- stuck in 1 language
- distributed, decentralized
- each function is an independent application with own server/db
- communicate through API calls
- API gateway redirects traffic to respective API
- end user does not notice that product is based on microservices
- independent deployment
- flexibility
- each service is developed separately
- loose coupling
- scale up individual services which require it
- fault-tolerant
- error is isolated to its service
- parallel programming
- more time and money to develop
- latency introduced through API calls
- OS is shared by different containers
- encapsulates microservices with dependencies as image
- deploy images
- logical separation (organization) of code
- ex. UI layer, logic layer, DAL
- physical separation (deployment)
- n-tier architecture
- each tier hosts a layer
- can host multiple layers in a single tier ex. combine logic layer and DAL as server tier
- UI
- logic, controllers
- data storage and handling
store data in kvp in fast volatile memory
- data in cache, unexpired
- return cached data
- data not in cache
- receive data from db, update cache, return data
- fast data retrieval
- reduce query load/times to db
- can temporarily substitute for db if db unavailable
- increased maintenance required
- data security
- must keep data fresh
- default
- if cache has data, return to data else call db and update cache
- no guarantee of data consistency between db and cache
- first request is always a miss, must spend time to write
- similar to above, but the application always requests from cache
- cache is DAL and handles all data operations
- cache grabs data from DB and updates itself
- the application only interacts with the cache and not the db
- application writes data to cache instead of db
- cache then immediately writes to db
- guaranteed data consistency
- increased write latency
- application writes data to cache instead of db
- cache periodically writes to db
- bear db downtimes
- lesser load on db
- increased write latency
- cache failure results in complete data loss
- manages and distributes network load across multiple servers
- optimizes speed by ensuring that no server is overloaded
- redirects requests to other servers
- adds and removes servers on demand
- usually stored on client side and shared with server
- under a distributed system with multiple servers and respective DBs, we want to reduce cache misses on user data
- load balancers will redirect requests from a user session to a single server
- use 1 active balancer until issue
- swap over to the passive balancer
- traffic is distributed over many servers using load balancing algorithm
- if you get ddosed your load balancer can offset it to your favourite cloud provider
- Cisco, TP-Link, etc. machines
- Nginx, AWS Elastic load balancing
- random
- sequential round robin
- IP hashing
- other hashing (ex. request URL)
- least connections
- fastest response time/fewest active connections
- perform distributed/parallel processing on large data sets
- split big data into chunks and process them in parallel on multiple servers
- it then merges and returns the processed data
- input is in form of kvp
- distribute data throughout the cluster of nodes, and each node will perform its computation
- takes result of map phase and reduces it down into single value
- distribute words into nodes
- Map s.t. key-value is (word, 1)
- sorting/grouping occurs where data of the same key (same words) are processed in the same node
- reduce returns a single value for each of the keys
- in this case, reduce will sum the key values (words) and return the word count
- connect distributed systems in real-time using events
- similar to observer, but the subject has no idea of the observers
- observer -> subscriber
- subject -> publisher
- broadcast
- publishers push to subscribers
- polling
- subscribers pull from publishers
- rent machines
- providees a service to develop/test/maintain software
- on-demand access of popular software
- redirect user browsing activity
- client sends request to proxy
- proxy forwards request to target server
- proxy returns obtained content
- hide IP address
- sits in front of servers and routes incoming requests to appropriate web servers
- protects servers on backend
- extra layer of security between network requests and server
- performs grunt work such as auth, caching, encryption/decryption for backend
- performance improvement
- can also act as load balancer (nginx)
- gateway to backend web servers