Amazon Interview Question
Software Engineer / DevelopersTeam: Amazon Video
Country: UK
Interview Type: In-Person
Halo,
In total awe…. So much respect and gratitude to you folks for pulling off such amazing blogs without missing any points on the #topic. Kudos!
I joined the Amazon affiliate site and received my access key id and my secret key.
There was a problem downlaoding and saving the secret key so I created another one.
I am submitting this information to Amazon to complete my affilaite site but Amazon is accepting the information.
I would appreciate any information as to why this may be ocurring.
I look forward to see your next updates.
Kind Regards,
Irene Hynes
In This mapping will also play a important role like As rsumanKumar mentioned that we need the entities like Topic, Message, User and Manager so mapping should be like Topic to Message have one to many mapping, Message to user have one to one mapping and user to Manager have many to one mapping.
Let us start designing the system.
- 4d August 21, 2017What is the functionality we need to support:
1. Post Messages on a Topic
2. Show All Messages under a Topic.
3. Search for a Topic
There can be other features, but let us restrict ourselves to these core features. We can always extend later.
What are our Entities?
1. Topic 2. Messages 3. Users.
Ok, Is this a Write-Heavy system or a Read Heavy System? I would say, read-Heavy ( Reads should be around 10/100 times more than writes- new posts would be not as frequent as post reads). From Scalability purpose, how do we scale our DB. We can use a MySQL DB with a Single Write Master and Multiple Read Slaves for scaling. This would hurt consistency - some users may not be able to see certain posts, but we should be fine with that at the cost of high availability. The problem here is that single master may not be enough , since our writes are also reasonably high. So, a sharded architecture would be preferrable. Should we shard using user_id, or post_id? Post_id should be preferred, so that all messages of a post go to same shard. We would use consistent hashing to distribute the posts to the shards, so that adding/removal of shards does not cause a problem.
Caching - We should cache the recent messages of each post and the recent posts- so that they can be fetched directly from cache, and do not need to hit the DB. We should use a separate Memcache/Redis Cluster for the Cache. This would be a write-Through Cache, so the recent posts would be written to the cache, and the cache would write to the db. This process should actually be asynchronous. When the user posts a message, we should push that to a message queue like SQS/Kafka and later consume these messages to write to the cache and then the DB.
MicroServices - We would ideally like to break out into multiple Services like ReadService and WriteService, so that they can scale separately. Distributed Transactions would be a challenge here, we should aim for eventual Consistency