Stefan Tilkov and Dare Obasanjo debate the number of big sites that would benefit from giving up on the relational database as a centerpiece of their systems. The parameter used in the discussion is scalability.
A number of the lessons learned from these big web sites could apply to smaller data center designs as well. The biggest problem I've seen in the typical data center, and from comparing notes, seems fairly common, is the ability evolve components relatively independently.
Relational databases can be in the mix and still evolve, just as more supposedly "loosely coupled" mechanisms can actually tie components tightly together. For example some systems may use asynchronous messaging to decouple with respect to time, but then pass to each other data that exposes implementation details. And so these systems are coupled to each other with respect to maintenance and enhancements: changing the implementation of component C demands corresponding changes to every other component that consumes component C's implementation-specific messages.
But the lessons are worth following for more reasons than just scalability.
3 comments:
> A common mistake that I have seen involves "messaging" of implementation-dependent content among components.
Would you mind re-phrasing as this is not a very clear point to me but I'm interested to know more.
Thanks
Thanks. I took another pass at it.
Thanks and your point is much clearer now. I agree that systems that pass implementation details are prone to be a pain to evolve, whether they use a distribute messaging system or not. But well, bad design is bad design, no matter the color of the paper you wrap it in :)
Post a Comment