SaaS VS PaaS VS IaaS
In SaaS, everything is managed by vendor and companies just need to use the application. Example: Google Apps, Apigee, Salesforce.
In PaaS, companies have to manage applications and data, rest all is managed by the vendors. Example: AWS Elastic Beanstalk
In IaaS, companies have to manage applications, data, middleware, OS and rest all is managed by the vendors. Example: AWS services, DigitalOcean
PaaS-oriented development- pros/ cons
With PaaS, IaaS it’s easy to get the product deployed and live in production, as we have to worry less about the infrastructure. The challenge is that some times these PaaS and IaaS have limitations or customization problems for company applications.
Solution Architect vs Enterprise Architect vs Technical Architect
Technical Architect offers technical leadership in projects. They focus on technology uses, like Java, databases, and offers their expertise in implementation and issues.
Solution architects on the other side are generally look over project tasks and activities and make make sure the implementation is done as per requirements. Mainly involved in requirements capturing, concept designing, implementation, and maintenance.
Enterprise architects work on enterprise activities and provide guidance or certain rules of implementation within the organization.
Often these roles are interchangeable.
BASE Property Of A System
Basically available (Highly available)
Soft state (State change over time)
Eventual consistency (Gets consistent after some time)
When to use RDBMS or NoSQL
Both database types have their own purpose and benefits.
RDBMS is good for structured data while NoSQL is good for flexible and complex data.
“RDBMS (SQL) encompasses relational databases that are a good fit for structured data,
while NoSQL encompasses flexible, non-relational databases that work well for complex, large-scale data.
Reporting and transactional use cases are more suited to SQL databases.
NoSQL has the flexibility for inconsistent data structures. They are good for scalability cases.
Twelve-Factor App principles
The Twelve-Factor App methodology is a methodology for building software as a service application.
Single Codebase
No Dependencies
Configurations stored in the environment
Attach detached Backing services
Build, release, run
Stateless Applications
Self Port binding for other services
Scaling Concurrency
Fast startup and shutdown for Disposability
Similar kind of Dev and Prod environment
logs as event streams
Admin Panel deploy with package
Heuristic Exceptions
Its one of the worst errors in the transaction system and can happen due to some system failures and can result in partial commit of data and not full rollback.
This leads to data integrity corruption. Some systems offer a transaction management system that can look at this corrupted data and edit/fix it.
Shared Nothing Architecture
Each node is independent and self-sufficient, and there is no single point of contention required across the system.The benefit is that no node is dependant on any other node, and if one fails, the other nodes will work perfectly. Nodes do not share any resources with each other.
Eventually Consistent
Here we have multiple nodes and once data is updated, it gets reflected each node. However, there can be a very short delay sometimes in updating one of the nodes.
This leads to Eventually Consistent, which means, there are chances that the data reflected after update may not be up to date immediately, but if we try after a short delay, it will show the latest updated data.
High Availability
It refers to the uptime of an application. A common practice to achieve this by using redundant server nodes with clustering.
Scalability
Scalability refers to handling high traffic load using Scaling up and Scaling out techniques.
Scaling Up: Adding more resources to the existing node.
Scaling Out: Adding more nodes.
Session Replication
Session replication can be used to avoid session failovers.
A user session gets replicated in all machines of a cluster and gets updated if there are updates.
This way, even if one node fails, and the user gets to another node, it will be able to handle service requests.
There is extra memory and network cost when we enable session replication.