Interview Question Software Architects
Country: United States
Interview Type: Phone Interview
If you want to notify other system services module you need to use communication module that may need pub-sub architecture. You may need to put update request in a queue so that all updates pass on to subscribed services.
* one way is to expose different register interfaces for different data interested. Anyother thoughts ?
* CatalogManager can assign some sequence numbers to each message and the clients can order the messages based on them.
* We would need Event Manager which models Pub-Sub pattern for sure. It is Event Manager's responsibility to ensure the messages reach the consumer. It could be implemented by keeping the outgoing messages in a queue and having some retry logic in the event manager if the message transfer fails.
* EventManager's responsibility to remove the message from the queue once the transfer is successful without exceptions. This will ensure the message is sent only once.
Abstract message service to a MessageCenter class.
@Singleton
public abstract class MessageCenter {
public static getInstance()
public push(Event e, Object data);
public on(Event e, EventHandler eh)
Enum EVENT_TYPE {
NEW_PROD
PROD_INFO_CHANGE
...
}
}
Catalog manager will push diff. kind of events when data updated. Other backends register to events they are interested in. Like
MessageCenter.getInstance.on(MessageCenter.EVENT_TYPE.NEW_PROD, new NewProdListener(data){//deal with the info...
}
Where to put message queue depends on which part have larger amount of transaction and need less delay. e.g. queueing message in each backend will make CatalogManager faster: it will just keep fireing events, and each backend will deal with eventually consistency. Given in your description, CatalogManager seems to touch all transactions, it'll easily become a bottleneck, I'd recommand queueing message in all other backends. Note for CatalogManager pushing events are async, so it won't block at all.
You can have an event class :---
Class Event
{
Seller id;
Product ID;
Map<attributeID, old value>
Map <attributeID, new value>
}
For shipping event you can make a new class inherited from event class having one more bool variable IsDimensionChanged. Other services will subscribe the event.
As soon as event will raise, you can insert in queue. As insertion is very common and we have to sync, we will make make multiple queues of small size, rather than making one queue for big size. Once one queue will full or after particular timeout, listener will start listening.
In this way, reader and writer will have lock on different queue.For updating database, we can use nosql database and update whole class of catalogue which has been modified in database along with catalogue id. It could be done after configured time.
For fault tolerant purpose, we can do 2 things :--
1- introduce event id which would be unique and pass in every message. Every subcriber will maintain of queue of those eventid which it has responded. This queue will flush after some time.
2- Every message queue would be written in memory mapped files with queue id. Once reader will read whole queue, they will remove this file. Therefore if fault will occur while reading, system will restore from least queue id file and start reading. this id could be timestamp.
Need more information.
- krishna January 20, 2015