Tuesday, May 30, 2017

Practices - Summary

Collating Few Top Practices for System Design & Architecture:
  1. Prefer a Stateless Design
    • Lifetime of your business objects is tied to the lifetime of a single request
    • Minimize Resource Contention – Thus Increase Performance - 
    • Ensure that business objects do not hold onto shared resources across calls. 
    • This helps reduce resource contention and increase performance
    • Avoid Server Affinity – Thus Increased Scalablity - Makes easier for you to ensure that you do not introduce server affinity, which restricts your scale-out options
  2. Separation of Concern - Achieved thru Layering
    • At a low level, this principle is closely related to the Single Responsibility Principle of object oriented programming.
    • Although the layered architecture pattern does not specify the number and types of layers that must exist in the pattern, most layered architectures consist of four standard layers: presentation, business, persistence, and database.
  3. Design for High Cohesion 
    • Achieved, when logically related entities, such as classes/ methods, are grouped together. Similarly, a component contains logically related classes.
    • This results in less round trips because the classes or components are logically grouped and may end up residing in same tiers
  4. Design for Loose Coupling between layers
    • At Business Layer – 
      • Use Abstraction (Can can be implemented using:)
        • Public Object Interfaces, 
        • Abstract Base Classes, or 
        • Separate interface from implementation – By providing Facades
        • Use Decorator, Bridge, Strategy Patterns
        • Follow OCP SOLID Principle - Software entities like classes, modules and functions should be open for extension but closed for modifications.
    • At Web applications –
      • Consider a Message-based communication between the presentation layer and the business layer
  5. Prefer n-Tier Architecture
  6. Caching
  7. Concurrency and Transactions - Appropriate Concurrency Model – Optimistic / Pessimistic 
    • Implement Compensating Methods where you cannot apply a commit or rollback to revert data store to its previous state should an operation in a transaction fail.
    • Avoid holding locks for long periods; for example, when executing long-running atomic transactions or when locking access to shared data.
    • Choose an appropriate Transaction Isolation Level, which defines how and when changes become available to other operations.
  8. Data Access
    • Avoid Mixing data access code and business logic within your business components, to increase scalability.
    • Avoid Directly Accessing the database from your business layer, instead prefer to have DAL in-between
    • Consider batching commands into a single database operation.
    • Decide whether you need - 
      • In Distributed Computing - IMMEDIATE/STRONG CONSISTENCY VS. EVENTUAL CONSISTENCY - Link
      • PESSIMISTIC CONCURRENCY VS.OPTIMISTIC CONCURRENCY -
        • Pessimistic approach:
          • Locks the row in advance to prevent others make any update.
          • Preferred when there are a lot of updates
          • Pessimistic locking requires overhead for every operation, whether or not two or more users are actually trying to access the same record. The overhead is small but adds up because every row that is updated requires a lock. 
        • Optimistic approach
          • Doesn’t actually lock anything – instead, it remember before image, and when it’s time to update it, the user asks the database to go ahead only if the row still looks like he remembers it. 
          • Preferred when low updates and possibility for conflicts is very low.
          • Allows fast performance and high concurrency (access by multiple users), at the cost of occasionally refusing to write data that was initially accepted but was found at the last second to conflict with another user's changes.
      • STATIC/EXPLICIT SCHEMA VS. DYNAMIC SCHEMA / SCHEMA-LESS / NO-SQL DB
  9. Deployment Considerations
    • Prefer Non-Distributed deployment:
      • Maximize application performance. 
      • But Reduces Overall Scalability & Maintainability 
    • Prefer Distributed deployment - 
  10. Evaluate Need For Server affinity - 
    • Server Affinity occurs when all requests from a particular client must be handled by the same server. 
    • Root Cause - It is most often introduced by below.
      • Locally Updatable Caches
      • In-Proc Session Mode - All requests from a specific client must be routed to the same server. 
      • Thread Affinity prone application-logic: This forces the thread to be run on a specific set of processors. This hinders the ability of the scheduler to schedule threads across the processors, causing a decrease in performance gains produced by parallel processing.
  11. Note:
    • Affinity can have a positive or negative impact on Performance And Scalability. 
    • More server affinity to a resource can bring Performance Benefits. On the other hand, it brings Scaling Out Problems.
    • Thus decide based on your needs.
    • A Web farm can be configured to route all requests from the same user to the same server – a process known as Affinity – in order to maintain state where this is stored in memory on the Web server. However, for maximum performance and reliability, you should use a separate session state store with a Web farm to remove the requirement for affinity.
  12. Use Asynchronous approach
  13. Effective Exception Management Strategy
  14. Effective Logging and Instrumentation strategy - Important for the security and reliability of your application.
  15. Efficient And Secure Session Management Strategy
  16. Prefer SOLID Design Principles
    • Single Responsibility Principle – SRP
      • A class should have only one reason to change.
      • This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. 
    • Open Close Principle - OCP
      • Classes, modules should be open for extension & closed for modifications.
      • Prefer Abstract Classes & Concrete Classes for implementing their behavior
      • Thus Concrete Classes can extend Abstract Classes instead of changing them
    • Liskov's Substitution Principle - LSP
      • Derived types must be completely substitutable for their base types.
      • I.e. Base class continue to work, if a derivative of base class is passed to it
    • Interface Segregation Principle - ISP
      • Clients should not be forced to depend upon interfaces that they don't use.
      • Avoid Polluted or Fat Interfaces.
    • Dependency Inversion Principle - DIP
      • High-level modules should not depend on low-level modules. 
      • Both should depend on abstractions and not concretions.
      • Abstractions should not depend on details. 
      • Rather Details should depend on abstractions.
  17. Prefer Micro-Services
  18. Re-Silent Architecture
    • Server less Architecture, Zero-administration Compute Platform (Lambda)
    • High Application Availability (Multi-Availability Zone)
    • High Application Reliability (Micro Services, Messaging System)
    • Auto Scalable & High Performance Application (ASG)
    • Elastic Load Balanced & Routing Policies Applied 
    • Secure & Cost Effective Solution
  19. Prefer REST over SOAP
  20. Prefer JSON over XML
  21. Understand OOPs Concept: Association/Aggregation/Generaliztion/Abstraction-Generalization/Specialization-Inheritance
  22. C# Myths
  23. Decide SQL vs NoSQL
  24. Decide MVC/MVP/MVVM
  25. Decide Design Patterns to apply

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.