Saturday, February 8, 2020

Leetcode solution 243: Shortest Word Distance

Problem Statement 

Given a list of words and two words word1 and word2, return the shortest distance between these two words in the list.
Assume that words = ["practice", "makes", "perfect", "coding", "makes"].
Input: word1 = “coding”, word2 = “practice”
Output: 3
Input: word1 = "makes", word2 = "coding"
Output: 1
You may assume that word1 does not equal to word2, and word1 and word2 are both in the list.
 Problem link

Video Tutorial

You can find the detailed video tutorial here

Thought Process

It is a bit confusing at first to be confused with the "Edit Distance" problem. However, there are duplicate words in the array, it's just a matter of finding the minimum distance between two words, where words could be found in multiple places in the array.

Brute force way (for each word, find the closest distance with the other word) would give you O(N^2) time complexity where N is the array size. An O(N) optimization would be having two indices for each word and keep updating the minimum distance. It is greedy because the closer the two elements are, the smaller the distance would be.

You can refer to Leetcode official solution for a detailed explanation.



Time Complexity: O(N) where N is the array size
Space Complexity: O(1) Constant space


Saturday, February 1, 2020

System design interview: how to design a chat system (e.g., Facebook Messenger, WeChat or WhatsApp)

System design interview: how to design a chat system (e.g., Messenger, WeChat or WhatsApp)

Methodology: READ MF!

For system design interview questions, normally we should follow the "READ MF!" steps. You can easily remember this as "Read! Mother Fucker!", similar to RTFM, with an attitude to your interviewer (Because if I can design this complicated system in 60 minutes, why would I waste my time interviewing here? JK)

READ MF! (Requirement, Estimation, Architecture, Details, Miscellaneous, Future)
  1. Requirement clarification, keep it simple first and make some assumptions to make your life easier, later we can drill down or improve.
  2. Estimation on scalability (QPS, storage size, network bandwidth per sec) the scalability determines the final architecture since we should not over engineering things, keep it simple first 
  3. Design system Architecture & Layers, major services and responsibilities, front-end/edge layer, service layer & storage layer 
  4. Drill down Details into each component, e.g, data models on storage layers, API interface between micro services 
  5. Miscellaneous. Talk about design trade-offs, bottlenecks, peak traffic handling, failover plan, monitoring & alerting, security concerns. Talk things that you are most comfortable with
  6. Future work on if new features are added, how system would be extended to support them

Key designs and terms 

  • WeSocket(On OSI 7, application layer) is more suitable for real time chatting over HTTP due to the bidirectional nature (HTTP long polling is also not efficient)
  • Maintaining connection efficiently. We should reuse those socket connections since it's not efficient to recreate them (still under IP&TCP), also utilize each machine in Chat Service to host more connections. In real world, WhatsApp tech stack Erlang + FreeBSD can host 1 Million connections per commodity host. 
  • Data storage solutions. For large volumn writes and range query (for latest messages), we might not want to go with relational database (write is not super efficient for large scale) and we want to read from memory as well. We could cache over a relational DB but we can also choose HBase (LSM Tree), Cassandra(SSTables) or even Redis
  • Sent, Delivered & Seen State are easy given the above graph. Sent is when Chat Service returns success. Delivered when message is written into the main coveration storage, Seen is when user pulls the latest chat history or connection is open chat service successfully pushed the message. Tying is simply a listener on the client side.

Baozi Youtube Video

Existing Resources (Credits to original authors)

  •  Rick Reed on F8 about WhatsApp Design [Video]
    • Culture is important! 57 engineers in total to reach 1B WhatsApp users, including clients and server sides 
    • Design principle: Just enough engineering. Only provide the most essential features. E.g., simple layers between services, go as native as possible for performance gains, simple data replication by keeping a hot copy
    • Small number of servers, each server support 1M connections. Not just about cost saving, also about easier to maintain (since you have less servers), How to scale to Millions of Simultaneous Connections: Video, Slide  
    • Transient messages when users are offline: WhatsApp won’t delete those messages unless all recipients get it
  • High Scalability: The WhatsApp Architecture Facebook Bought For $19 Billion
  • Tushar Roy on Youtube