CareerCup

1. Improve metrics on the system

	- First I'd like to divide the system in the following units:
		○ Web portion/UI
		○ Web servers
		○ Application servers
		○ Database servers
		○ Operating systems used on the servers
		○ APIs where the business logic lies
		○ Cache
		○ Asynchronous processing

	- Second I'd like to get answers to some general questions related to the usage of the system:
		○ Are the page views more on mobile or desktops?
		○ How many pages are visited in a day?
		○ How long users spend on the page?
		○ How much data do we expect to handle?
		○ How many requests per second do we expect to handle?
		○ What is the expected read and write ratio?
		○ How many years worth of data do we expect to store?
		○ Are there any media involved?
		○ Is there analytics involved?
		○ Do we need to analyze the click stream data?
		○ How much latency is acceptable?
		○ Which parameter do we give weightage on - consistency of data or availability of data?

	- Taking each of these questions I'd now like to point out possible options on each of our system:
		○ Web portion/UI:
			§ If the system is a real-time game application like Shooter or Car chase or Voip, Video chat application:
				□ Use UDP:
					® Connectionless
					® Unreliable but only 1-5% of datagrams will be lost
					® TCP queues up the data before sending out to server, with UDP we will get data as quickly as possible
					® If TCP loses the packets or arrive out of order, it basically just stops and tries to rearrange them. It again queues up before sending.
					® Not a good idea to mix TCP and UDP, application logic becomes complex
				□ Use HTTP long polling because Websockets are not supported on UDP:
					® Maintain the sessions in Redis just in case either side goes down, they can find the connections quickly by querying Redis
			§ If system is real-time turn based game like chess or blackjack:
				□ Use TCP:
					® We cannot afford the moves being lost due to lost datagram packets
					® TCP will take care of sending the packet again
					® Moves cannot be more than 5 per second so UDP is not required
				□ Use Websockets:
					® Websockets are built on TCP
					® They are persistent connections. Client/Server reuses the connections.
					® Duplex connections so server can respond to client
					® Interaction is stateful. If a connection is opened through LB to a server, it stays with the same server.
			§ Other improvements which can be done on UI:
				□ Make fewer HTTP requests
				□ Use CDN for faster loading of data. CDN are geographically located caches where data.
				□ Add Expires header in HTTP requests so that expires in cache
				□ Put stylesheets on top
				□ Put scripts at bottom
				□ Minify the Javascript files
				□ Avoid CSS expressions
				□ Make AJAX cacheable
		○ Web Server:
			§ Use a reverse proxy on Webservers:
				□ They can black list Ips
				□ They have a cache of their own and can cache static content of the Web pages
				□ They support GZIP compression so it will consume less bandwidth
				□ They are SSL terminated - So they can decrypt and encrypt the data before sending it to the backend servers. This saves the encryption/decryption logic to be on the backend servers
				□ They can also act as load balancers for the backend application servers
		○ Application Server:
			§ Do you  need compute or memory optimized instances?
		○ Database server:
			§ Horizontal scaling
			§ Vertical scaling
			§ Sharding
			§ Master-Slave replicas
			§ Do we need RDBMS or NoSQL or is it Polyglot persistence?
			§ Denormalization
			§ Indices
		○ Caches:
			§ CDN
			§ Reverse Proxy caches
			§ Application caches - Memcached or Redis
			§ Database caching - query responses
			§ Cache strategy - cache-aside, cache-through
		○ Message queues:
			§ RabbitMQ - offloads the non time critical data to be processed offline
			§ For example, write a tweet, show it on user's timeline, but in background hand it over to a queue to be processed to shown on all the follower's timeline
Have celery as worker, let it process all the queue data in parallel, update the Redis and let the Read API read from the Redis - separation of concerns

What sort of questions did you ask, if you don't mind telling us

Here are some of the questions you can ask that would take the discussion further:
1. What metrics are tracking today?
2. What are the problems with it?
3. Is this a system limitation (here you can talk about problems of scale) or do we need to track more relevant metrics
4. What are the goals - do we want to improve user experience, drive more sales or more of an system optimization such as better inventory management.

The interviewer will then likely lead the discussion where they intended to. This could be very technical (gauging your depth) or they may just be gauging if you are thinking of the problem broadly enough.