Collating Few Top Practices for System Design & Architecture:
- 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
- Note:
- Stateless Service: A stateless service is a type of service is considered stateless because the service itself does not contain data, instead data is persisted to an external store, such as Azure Tables or a SQL database that needs to be stored reliably or made highly available. If an instance of a stateless service shuts down, all of its internal state is lost.
- Stateful Service: A stateful service can maintain state reliably within the service itself, co-located with the code that's using it. State is made highly available by Service Fabric/App Fabric without the need to persist state to an external store.
- Good Links:
- 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.
- 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
- 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
- Prefer n-Tier Architecture
- Caching
- 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.
- 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
- Deployment Considerations -
- Prefer Non-Distributed deployment:
- Maximize application performance.
- But Reduces Overall Scalability & Maintainability
- Prefer Distributed deployment -
- Easily Scale Out Or Scale Up
- But cost additional Serialization & Network Latency
- 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.
- 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.
- Use Asynchronous approach
- Effective Exception Management Strategy
- Effective Logging and Instrumentation strategy - Important for the security and reliability of your application.
- Efficient And Secure Session Management Strategy
- 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.
- Prefer Micro-Services-
- 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
- Reduce Over Communication Between MicroServices - Use Circuit Breaker, Fallbacks etc
- Use Appropriate DB & Storage Technology - SQL for Consistency, No-SQL for Scalability
- Implement Caching - Increases Scalability, Increase Resilience by supporting techniques like Graceful Degradation.
- Secure & Cost Effective Solution
- Links
- Prefer REST over SOAP
- Prefer JSON over XML
- Understand OOPs Concept: Association/Aggregation/Generaliztion/Abstraction-Generalization/Specialization-Inheritance
- http://arun-architect.blogspot.com/2014/06/oops-concepts.html
- Association (*a*),
- Aggregation (*the*)
- Composition(*has*)
- Inheritance (*is-a*)
- C# Myths
- Decide SQL vs NoSQL
- Decide MVC/MVP/MVVM
- Decide Design Patterns to apply
- Creational - Abstract Factory, Factory, Singleton
- Structural - Adapter, Bridge, Composite, Decorator, Facade
- Behavioral - Observer, Strategy, Command
- Web Application Security & Non-Hacking Techniques: Link
- ORM - Comparison
- Performance Tuning/Best Practices
Project Management Practices:
- How Good Are At Behavioral Skills
- How Good Are Your PM Skills
- How/What to Start New Project - Traditional
- How to Start New Project - Agile
- What is Project Plan
- How to Handle Change Request
- How to Manage Project Delays
- Why Estimate in Story Points
- Three Amigos in Agile
- Risk Management in Agile
- Project Initiation Document
- Todo When Closing Project
- Great Manager & Leadership Styles
- Cloud Products
- PM Related Questions
Regards,
Arun Manglick
