Alex Staveley is a software professional passionate about software engineering and technical architecture. He blogs about architectural approaches, Java topics, web solutions and various technical bits and pieces. Alex is a DZone MVB and is not an employee of DZone and has posted 48 posts at DZone. You can read more from them at their website. View Full User Profile

Book Review: 'Scalability Rules: 50 Principles for Scaling Web Sites'

  • submit to reddit
I absolutely love Technical Architecture. It is something that requires high standards in engineering to do well.  In 'Scalability Rules', Martion Abbott and Michael Fisher list 50 tips where each tip communicates a simple or sophisticated idea in a few short pages. Their ideas are based from real world experience of working with over 200 internet architectures.

Performance and its cousin Scalability are always an important part of any software architecture and while some cynics will say some of the tips in this book are common sense, there's plenty of really good advice that if adhered to they would certaintly lower the probability of scalability issues which are nearly inevitable at some stage in the life of a project.

Among my favourites tips:
  • Put Object caches on their own tier. This makes it easier to size their hardware needs - object caches typically need a lot of memory.
  • Pass on multi-phase commits if possible as they are difficult to scale.
  • Smart reminders when it is really important to use aschronous models (integrating with 3PP frameworks, when there is a temporal constraint).
I wouldn't just recommend individuals to read this book, I would recommend teams. Some important ideas such as spliting up system processing by something like customerId are given concrete names such as Z-Axis splits. The would help teams speak start speaking the same language when communicating ideas. It would help to remind teams that some simple things such as using logfiles, monitoring your system and not relying on QA to find faults are very important and should not be forgotten.

In summary, there are not too many good books on software architecture and this is certainly one of the best I have read. I have already read parts of it 3 times and I am sure I will be referring to parts of it again.
Published at DZone with permission of Alex Staveley, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Daniel Slazer replied on Tue, 2012/06/12 - 12:35pm

Let's take another tack. Your derived class constructor calls super() implicitly, i.e. the base class constructor. At that moment the 'base object' has to exist. Let's also consider that the actual base class you are talking about contains no fields so has no visible memory cost at all. And let's also consider that if it did have fields, they would have to be initialized when its constructor was called. On all these grounds, there is no part of the 'base object' creation that could possibly be deferred. So once again your question fails to make sense. I don't know what makes you think you know more about language design than the guys who did design the language. You should rethink that assumption.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.