The other night, after evaluating a job offer torrenegra posted, I looked at their letmego architecture. This is what I think:
Here is a diagram I took (without their permission, sorry)
LetMeGo Architecture
I wonder why did they took those odd choices in their architecture. One thing is clear, each individual module has to be fast, pretty fast. (Is it?*)
There is one thing that makes me think… how many times do I have to serialize and deserialize an object in order to operate. Let’s pretend that in order to make a booking, I have to go first to the Marrley Subsystem(booking), then to Hendrrix (User) and Sinatra (Lodging) and thats it (I guess it will take more work in real life…) and back. That means I have to serialize and deserialize info about 6 times. Let’s say that in order to serialize an object, it would take about 1ms (from my own experience), let us assume 3 objects to transfer in each call. That means that only in this communication between subsystems, I’ve lost 18ms. Doesn’t seem like much, right? Expect 1 million users and that would be 5 hours of processing time in just handling the serialization/deserialization. (And I’m only thinking about 1user doing 1 operation).
Security Point Of View
From a security point of view it also has some downs: assume that each subsystem is necessary to LetMeGo to operate… let’s say that each subsystem has 5 servers running in tandem, each one with a Service Level of 99.95%. That means that each subsystem has a SL of 99,95%. The system, having 10 subsystems, would have an SL of 99.5% (3 hours 36 mins downtime/month Worst Case Scenario). However, if all the servers ran the whole system and they were running in tandem, the SL would be 99.95% (~21.6 mins downtime/month Worst Case Scenario).
Bottlenecks?
I don’t know exactly how the subsystems interact with each other, but I’ll fear bottlenecks… This architecture depends (I assume) on communication between subsystems, so a bottleneck would slow down the whole system…
I do like the fact that this architecture forces the designer to really create modules that enable very low coupling. In fact, each of those modules could be easily replaced and the system would continue to work without noticing it. This is sometimes extremely hard to get unless you’re a pretty good designer, and this architecture doesn’t let you fail at this.
Yes, nobody likes dirty data. Data normalization is one of the most common patterns we take for granted when designing a new application. However, large applications like flickr have shown us that having data replication can help your app be quicker and therefore grow larger…
I’ll then have data replication almost everywhere: reading is then damn fast, altough writing isn’t. However, I know that most of the time you read data and sometimes only, you write. So, you have to optimize your reads! The less “joins” you have, the faster you’ll read! (Google App Engine even forces you to not have joins at all). So I’ll guess I’ll create a data replication scheme all the way between subsystems.
What happens when one subsystem fails? Most of them fail would fail too. So I guess I would create a mini System running somewhere running the whole system together so I have a contigence plan in case something went wrong with any subsystem.
I love to see new architectures. Is only this way that we discover new things, by having people that take risks.I do hope that LetMeGo will be as huge success as other torrenegra products had been in the past.
Merrcury is, for sure, a new architecture… let’s see how things go 
I already have many blogs… they all have their own purpose….this one its gonna be me, telling what I feel about tech world….
