More “Test Drivel”
Less than a week after posting the earlier article, I received an invitation to apply for a role on one of the invitation-only sites.
Rather than approaching a pre-selected set of candidates with any respect or even civility, once I clicked ‘interested’, I almost immediately received a link to one of those generic online tests. Aside from the hypocrisy involved in writing such a test days after slamming the whole idea, taking a test for a role I know little about other than a brief job description, and where I’ve not even spoken with anyone at the company, seemed beyond ridiculous.
I responded to the originator of the email and to two of the representatives of the site. While it was nice to receive apologies from the site representatives, the HR person involved didn’t bother to reply.
However, I did reply a second time. This time I said that if the person who would be responsible for the technical interview would take my test, I would take theirs. Below is my test.
You have 1.9M lines of existing transactional Java EE code. The Java EE cluster you’ve been using is no longer able to handle the workload, and you need to develop a transactional system that can handle 500,000 TPM to meet the demands projected for the next 5 years). Transactions arrive into the system via JMS containing verbose XML.
By calculating the time needed in a distributed in-memory cache such as memcached, deploying 3000 nodes, taking into account the time needed to locate and transfer data, load it in your VM and execute the appropriate code on it, you’ve estimated that such a system could handle 150% more TPM than the current 64 node Java EE cluster, which handles ~80,000 TPM.
That number though is decreasing, due to so many external vendors needing to be notified (such as air miles, Visa points, developer payments for in-app purchases, etc.) and an acknowledgement received prior to closing a transaction.
The JMS messages must be separated as they come into the system, into those that can be executed in parallel and fully transactional message sets that need to be handled serially. Related messages that are part of a transaction don’t necessarily come in together, or even in order — unrelated messages often arrive in between. Those transactional requirements make simple solutions such as JGroups or Java concurrent executors nowhere near sufficient.
How would you go about designing such a system? What technologies would you favour and in what type of architecture?
