Amazon Interview Question
SDE-2sCountry: India
Interview Type: In-Person
I believe, we can implement observer pattern between all application servers serving as event creator and a listener working as a observer which is subscribed to this app servers. The moment desired condition is encountered in any app server, it calls its update function to pass on this information to the listener (could be a messaging queue), and then listener pass on the this message to a parser module which will parse the message and accordingly will send the message to the concrete implementation of logging interface (Error, Warning, DiskFull... etc)
This way the system remains open to be scaled in future.
1. New app servers can be added in future. All it has to do is to implement the subject Interface and implement the functionality to register the observer.
2. Observer (listener will have to subcribe to the new subject)
3. In case new pattern comes (Out of Memory, Application Error...) in future, they will have their own concrete implementation of logging interface.
In total allowing all major actors to be independent to each other.
1) What kind of alarms will be raised? (emails, pageouts) -
We can have an alarming interface on the server side and each type of alarm (email, pageout) will implement it and using a factory class we can get appropriate instance of alarm system.
2) Does data need to be logged for future reference and how long?
3) How often patterns change ?
If they change frequently, we can implement observer pattern where the logging process running on each app server will register itself as observer. Every new pattern added on the logging system will be distributed to all app servers.
4) For notifying logging system about the events, we can either use simple messaging service.
Logging System
1) Pattern database and Pattern publisher.
2) Event Collector (messaging service)
3) Alarm Interface and implementing classes.
4) Event database
5) GUI to add new patterns and view event history.
App Server
1) Daemon process monitoring the patterns distributed by logging system.
Hi ,
1. We can use messaging and send the JMS message for each of the logging events
2. The JMS message has a header property set to true in case of an exceptional event.
3. All the messages with header property as true will be sent to a separate destination queue for raising alarms
4. The alarm raising system will read from the queue and raise an alarm.
5. Since we are using messaging the system can be scaled up
I believe, we can implement observer pattern between all application servers serving as event creator and a listener working as a observer which is subscribed to this app servers. The moment desired condition is encountered in any app server, it calls its update function to pass on this information to the listener (could be a messaging queue), and then listener pass on the this message to a parser module which will parse the message and accordingly will send the message to the concrete implementation of logging interface (Error, Warning, DiskFull... etc)
- Chandresh September 19, 2016This way the system remains open to be scaled in future.
1. New app servers can be added in future. All it has to do is to implement the subject Interface and implement the functionality to register the observer.
2. Observer (listener will have to subcribe to the new subject)
3. In case new pattern comes (Out of Memory, Application Error...) in future, they will have their own concrete implementation of logging interface.
In total allowing all major actors to be independent to each other.