Arun Manglick - About Me: Practices

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

http://arun-architect.blogspot.com/2010/12/n-tier-architecture.html

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-

http://arun-architect.blogspot.com/2016/11/microservices-soa.html

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