A Self-Denial Attack describes a situation where the system, or its users, conspire against itself. The "select offer" sent to 10,000 users is likely to become 1 million users due to network effects, such as people tweeting a discount code trying to get that $100 iPad. Deep links that bypass the front layer of your web site is an example of something that contributes to Self-Denial, because the deeper links aren't likely to have any special provision for extra traffic like a special landing page might. Sites go dark because they can't handle the unexpected load. In a horizontal architecture, it is possible that a single rogue server can bring down an entire layer. A single server that manages cache coherency or a lock manager are examples of where the failure of a single server can hose the entire layer. Strive for a "share nothing" architecture. If that is not possible look to use Decoupling Middleware or hot standby techniques. Design in a fall back protocol to deal with the situation when the shared resource is not available. Dedicate a portion of your system to that new promotion so that if it melts down, the remaining portion of the system can still function. Remember to fail fast when something goes dark so that calling layers don't hang waiting for an answer that is never going to come. Communication is a prime defense against a coming surge of transactions based on a promotion or campaign.
Keep lines of communication open. Since Self-Denial attacks originate from within the organization you can't account for campaigns unless you know about them. Never use deep links, use a landing page instead that can direct traffic as needed. Watch out for embedded session ids in URLs which can strain the system as it tries to manage sessions. Protect shared resources. Figure out how not make them a single point of failure. Expect rapid redistribution of any cool or valuable offer -- retweets and bargain hunting sites can multiply the expected traffic.
No comments:
Post a Comment