There are a few questions i would asked here.
- are the complete 1M users trying to visit the website from. a single region
- are there any other backend calls that needs to be done or the website just handles counting the no of people visiting
- when we say currently do they want to know per second or do they want to know per minute?
Approach :
there are ~700 requests that comes in per min if we consider uniformity so we can design a backend system that would be scaled horizontally based on the traffic (assumption is that we can have a good amount of available resources to scale). a loadbalancer to balance traffic from different regions.
it is better to have 2 API's defined so that we can increment the count as soon as the api is hit where as another api is being continuously called for the count
we can store count in redis( one DB write in central region) we need a lock here because if there is a parallel write, redis takes the last write. we replicate the redis cache on all regions just to optimize some performance and make it access easier to read thus reducing the load.
It gets a lot trickier if all the requests are from the same region , and if we make the worst case assumption we can have all 1M requests coming in 1second and nothing else in rest of the day. so this would put a limitation on how much we can replicate or scale.Here we might have to get into a LLD where we would have to optimally write the code. check what kind of the protocol requests can be made to reduce latency(probably a grpc vs rest). we might have to think about a queeing system so that we can send only x requests optimally and not crash the system by sending 1M loads.
No comments:
Post a Comment