Software Architectural Interview Question Part 1

What Is Load Balancing?

Load balancing is simple technique for distributing workloads across multiple machines or clusters. The most common and simple load balancing algorithm is Round Robin. In this type of load balancing the request is divided in circular order ensuring all machines get equal number of requests and no single machine is overloaded or underloaded.

The Purpose of load balancing is to

Optimize resource usage (avoid overload and under-load of any machines)
Achieve Maximum Throughput
Minimize response time
Most common load balancing techniques in web based applications are

Round robin
Session affinity or sticky session
IP Address affinity

What Is CAP Theorem?

The CAP Theorem for distributed computing was published by Eric Brewer. This states that it is not possible for a distributed computer system to simultaneously provide all three of the following guarantees:

Consistency (all nodes see the same data even at the same time with concurrent updates )
Availability (a guarantee that every request receives a response about whether it was successful or failed)
Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

The CAP acronym corresponds to these three guarantees. This theorem has created the base for modern distributed computing approaches. Worlds most high volume traffic companies (e.g. Amazon, Google, Facebook) use this as basis for deciding their application architecture. It’s important to understand that only two of these three conditions can be guaranteed to be met by a system.

Define Microservice Architecture

Microservices, aka Microservice Architecture, is an architectural style that structures an application as a collection of small autonomous services, modeled around a business domain.

Software Architectural Interview Question

Why use Web Socket over Http?

A Web Socket is a continuous connection between client and server. That continuous connection allows the following:

Data can be sent from server to client at any time, without the client even requesting it. This is often called server-push and is very valuable for applications where the client needs to know fairly quickly when something happens on the server (like a new chat messages has been received or a new price has been updated). A client cannot be pushed data over http. The client would have to regularly poll by making an http request every few seconds in order to get timely new data. Client polling is not efficient.

Data can be sent either way very efficiently. Because the connection is already established and a web Socket data frame is very efficiently organized, one can send data a lot more efficiently that via an HTTP request that necessarily contains headers, cookies, etc…

What do you mean by lower latency interaction?

Low latency means that there is very little delay between the time you request something and the time you get a response. As it applies to web Sockets, it just means that data can be sent quicker (particularly over slow links) because the connection has already been established so no extra packet roundtrips are required to establish the TCP connection.

What Is Scalability?

Scalability is the ability of a system, network, or process to handle a growing amount of load by adding more resources. The adding of resource can be done in two ways

Scaling Up
This involves adding more resources to the existing nodes. For example, adding more RAM, Storage or processing power.
Scaling Out
This involves adding more nodes to support more users.
Any of the approaches can be used for scaling up/out a application, however the cost of adding resources (per user) may change as the volume increases. If we add resources to the system It should increase the ability of application to take more load in a proportional manner of added resources.

An ideal application should be able to serve high level of load in less resources. However, in practical, linearly scalable system may be the best option achievable. Poorly designed applications may have really high cost on scaling up/out since it will require more resources/user as the load increases.

Advance Software Architectural Interview Question

Why Do You Need Clustering?

Clustering is needed for achieving high availability for a server software. The main purpose of clustering is to achieve 100% availability or a zero down time in service. A typical server software can be running on one computer machine and it can serve as long as there is no hardware failure or some other failure. By creating a cluster of more than one machine, we can reduce the chances of our service going un-available in case one of the machine fails.

Doing clustering does not always guarantee that service will be 100% available since there can still be a chance that all the machine in a cluster fail at the same time. However it in not very likely in case you have many machines and they are located at different location or supported by their own resources.

What Is A Cluster?

A cluster is group of computer machines that can individually run a software. Clusters are typically utilized to achieve high availability for a server software. Clustering is used in many types of servers for high availability.

App Server Cluster
An app server cluster is group of machines that can run a application server that can be reliably utilized with a minimum of down-time.
Database Server Cluster
An database server cluster is group of machines that can run a database server that can be reliably utilized with a minimum of down-time.

What is Domain Driven Design?

Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities, tasks, events, and data within a problem domain into the technology artifacts of a solution domain.

It is all about trying to make your software a model of a real-world system or process.

Software Architectural Interview Question

What is meant by the KISS principle?

KISS, a backronym for “keep it simple, stupid”, is a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore simplicity should be a key goal in design, and that unnecessary complexity should be avoided.

Why is it a good idea for “lower” application layers not to be aware of “higher” ones?

The fundamental motivation is this:

The most obvious example is ripping the bottom layer out and substituting a different one. This is what you do when you develop the upper layer(s) against a simulation of the hardware, and then substitute in the real hardware.

Also layers, modules, indeed architecture itself, are means of making computer programs easier to understand by humans.

What does the expression “Fail Early” mean, and when would you want to do so?

Essentially, fail fast (a.k.a. fail early) is to code your software such that, when there is a problem, the software fails as soon as and as visibly as possible, rather than trying to proceed in a possibly unstable state.

Fail Fast approach won’t reduce the overall number of bugs, at least not at first, but it’ll make most defects much easier to find.

Advance Software Architectural Interview Question

What does “program to interfaces, not implementations” mean?

Coding against interface means, the client code always holds an Interface object which is supplied by a factory.

Any instance returned by the factory would be of type Interface which any factory candidate class must have implemented. This way the client program is not worried about implementation and the interface signature determines what all operations can be done.

This approach can be used to change the behavior of a program at run-time. It also helps you to write far better programs from the maintenance point of view.

What is Elasticity (in contrast to Scalability)?

Elasticity means that the throughput of a system scales up or down automatically to meet varying demand as resource is proportionally added or removed. The system needs to be scalable to allow it to benefit from the dynamic addition, or removal, of resources at runtime. Elasticity therefore builds upon scalability and expands on it by adding the notion of automatic resource management.

What are the differences between continuous integration, continuous delivery, and continuous deployment?

Developers practicing continuous integration merge their changes back to the main branch as often as possible. By doing so, you avoid the integration hell that usually happens when people wait for release day to merge their changes into the release branch.
Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.
Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There’s no human intervention, and only a failed test will prevent a new change to be deployed to production.

Software Architectural Interview Question

What Is BASE Property Of A System?

BASE properties are the common properties of recently evolved NoSQL databases. According to CAP theorem, a BASE system does not guarantee consistency. This is a contrived acronym that is mapped to following property of a system in terms of the CAP theorem:

Basically available indicates that the system is guaranteed to be available
Soft state indicates that the state of the system may change over time, even without input. This is mainly due to the eventually consistent model.
Eventual consistency indicates that the system will become consistent over time, given that the system doesn’t receive input during that time.

Do you familiar with The Twelve-Factor App principles?

The Twelve-Factor App methodology is a methodology for building software as a service applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.

Codebase – There should be exactly one codebase for a deployed service with the codebase being used for many deployments.
Dependencies – All dependencies should be declared, with no implicit reliance on system tools or libraries.
Config – Configuration that varies between deployments should be stored in the environment.
Backing services All backing services are treated as attached resources and attached and detached by the execution environment.
Build, release, run – The delivery pipeline should strictly consist of build, release, run.
Processes – Applications should be deployed as one or more stateless processes with persisted data stored on a backing service.
Port binding – Self-contained services should make themselves available to other services by specified ports.
Concurrency – Concurrency is advocated by scaling individual processes.
Disposability – Fast startup and shutdown are advocated for a more robust and resilient system.
Dev/Prod parity – All environments should be as similar as possible.
Logs – Applications should produce logs as event streams and leave the execution environment to aggregate.
Admin Processes – Any needed admin tasks should be kept in source control and packaged with the application.

What are Heuristic Exceptions?

A Heuristic Exception refers to a transaction participant’s decision to unilaterally take some action without the consensus of the transaction manager, usually as a result of some kind of catastrophic failure between the participant and the transaction manager.

In a distributed environment communications failures can happen. If communication between the transaction manager and a recoverable resource is not possible for an extended period of time, the recoverable resource may decide to unilaterally commit or rollback changes done in the context of a transaction. Such a decision is called a heuristic decision. It is one of the worst errors that may happen in a transaction system, as it can lead to parts of the transaction being committed while other parts are rolled back, thus violating the atomicity property of transaction and possibly leading to data integrity corruption.

Because of the dangers of heuristic exceptions, a recoverable resource that makes a heuristic decision is required to maintain all information about the decision in stable storage until the transaction manager tells it to forget about the heuristic decision. The actual data about the heuristic decision that is saved in stable storage depends on the type of recoverable resource and is not standardized. The idea is that a system manager can look at the data, and possibly edit the resource to correct any data integrity problems.

Advance Software Architectural Interview Question

What Is Shared Nothing Architecture? How Does It Scale?

A shared nothing architecture (SN) is a distributed computing approach in which each node is independent and self-sufficient, and there is no single point of contention required across the system.

This means no resources are shared between nodes (No shared memory, No shared file storage)
The nodes are able to work independently without depending on each other for any work.
Failure on one node affects only the users of that node, however other nodes continue to work without any disruption.

This approach is highly scalable since it avoid the existence of single bottleneck in the system. Shared nothing is recently become popular for web development due to its linear scalability. Google has been using it for long time.

In theory, A shared nothing system can scale almost infinitely simply by adding nodes in the form of inexpensive machines.

What Does Eventually Consistent Mean?

Unlike relational database property of Strict consistency, eventual consistency property of a system ensures that any transaction will eventually (not immediately) bring the database from one valid state to another. This means there can be intermediate states that are not consistent between multiple nodes.

Eventually consistent systems are useful at scenarios where absolute consistency is not critical. For example in case of Twitter status update, if some users of the system do not see the latest status from a particular user its may not be very devastating for system.

Eventually consistent systems can not be used for use cases where absolute/strict consistency is required. For example a banking transactions system can not be using eventual consistency since it must consistently have the state of a transaction at any point of time. Your account balance should not show different amount if accessed from different ATM machines.

What defines a software architect?

An architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers’ feature requests.

Software Architectural Interview Question

What is Test Driven Development?

Test Driven Development (TDD) is also known as test-driven design. In this method, developer:
first writes an automated test case which describes new function or improvement and
then creates small codes to pass that test, and
later re-factors the new code to meet the acceptable standards.

What Are The Major Issues Associated With Managing Product Line Evolution?

Adopting a product line paradigm creates an organizational shift. Managing product line evolution is the most difficult part of the paradigm. The product line will change as new versions of the current product come out. An organization would need to use the new versions to satisfy changing client needs. Additionally, new improvements to various components may change the way the products are built. New version of components may not be entirely backward compatible, thus additional rework will need to be done to accommodate the changes.

What Is The Basic Approach To Problem Solving In The Blackboard Framework?

The blackboard framework is a dynamic group of independent entities that communicate and work together in order to solve some common problem. The knowledge sources adds a solution piece to the blackboard data structure when they (independently) think it’s appropriate. There is no centralized control mechanism that makes decisions as to when a knowledge source needs to contribute some piece of information. Rather the control entity states the conditions of when and each knowledge source need to contribute. The knowledge sources observe the commotion on the blackboard and contribute to progress independently.

Advance Software Architectural Interview Question

What Are The Components Of The Blackboard Model?

The blackboard model is usually composed of three components: knowledge sources, blackboard data structure, and control. The knowledge source component represents the chunks of information that is needed in order to solve a problem. These sources are separate from each other. The blackboard data structure can be looked at as a repository for the final solution. In this storage receptacle the final solution is slowly developed based on the sources and controls used. The control is not a module, but rather a mechanism or an abstract algorithm that specifies how a problem will be solved.

When Is Middleware Not Appropriate?

Middleware can get very complex and difficult to develop. The difficulties arise from the need to know the location of the servers and the amount of low-level details exposed. Certain domain specific systems with hard real-time systems may not afford to use a middleware services as that may slow down transaction speeds between an OS and applications. If a development company does not trust the middleware vendors, due to the secrecy of client’s data transmitted between databases and some applications, then that company may need to implement such middleware layer in-house.

What Kinds Of Changes Are Difficult For An Object-oriented System To Handle?

Managing changes to an object’s identify is the most significant disadvantage of an object-oriented system. If an identify of an object changes, then all other objects that use that identify must be updated in order to reflect the change in just one object. Manageability of various objects becomes a major issue.

Software Architectural Interview Question

What Problems Does Architecture Analysis Solve?

Software defects that lead to security problems come in two major flavors:

bugs in the implementation and
flaws in the design.
Implementation bugs in code account for at least half of the overall software security problem. The other half involves a different kind of software defect occurring at the design level. The division of design flaws and bugs is about 50/50. Both need to be secured to ensure your software’s well-being. You can institute the best code review program on the planet, with the strongest tools known to humanity, but it’s unlikely that you will be able to find and fix flaws this way.

4 ways to identify flaws

Analyze fundamental design principles.
Assess the attack surface.
Enumerate various threat agents.
Identify weaknesses and gaps in security controls.
It is far more cost-effective to identify and remediate design flaws early in the design process than to patch flawed design implementations after deployment. Architecture risk analysis (ARA), Threat Modeling, and Security Control Design Analysis (SCDA) are useful in finding and fixing design flaws.

SCDAs are a light-weight approach to ARA. They take less time to conduct and can be carried out by a much larger talent pool than traditional ARA reviews. Most importantly, the lightweight approach is efficient enough that it can be scaled to cover an entire application portfolio.

Organizations failing to integrate architecture and design reviews in the development process are often surprised to find that their software suffers from systemic faults both at the design level and in the implementation. In many cases, the defects uncovered in penetration testing could have been identified more easily through other techniques—earlier in the life cycle. Testers who use architecture analysis results to direct their work often reap greater benefit.

What’s The Relationship Between Software Architecture And Software Design?

Software architecture exposes the structure of a system while hiding the implementation details. Architecture also focuses on how the elements and components within a system interact with one other. Software design delves deeper into the implementation details of the system. Design concerns include the selection of data structures and algorithms, or the implementation details of individual components.

Architecture and design concerns often overlap. Rather than use hard and fast rules to distinguish between architecture and design, it makes sense to combine them. In some cases, decisions are clearly more architectural in nature. In other cases, decisions focus heavily on design and how it helps to realize that architecture.

An important detail to note is that architecture is design, but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There are no rules or guidelines that fit all cases—although, there have been attempts to formalize the distinction.

Current trends in software architecture assume that the design evolves over time and that a software architect cannot know everything up front to fully architect a system. The design generally evolves during the implementation stages of the system. The software architect continuously learns and tests the design against real world requirements.

What Is Software Design?

Software design is the process of conceptualizing the software requirements into software implementation. This is the initial phase within the software development life cycle (SDLC)—shifting the concentration from the problem to the solution.

When conceptualizing the software, the design process establishes a plan that takes the user requirements as challenges and works to identify optimum solutions. The plan should determine the best possible design for implementing the intended solution.

Software design includes all activities that aid in the transformation from requirement specification to implementation.

Major artifacts of the software design process include:

Software requirements specification: This document describes the expected behavior of the system in the form of functional and non-functional requirements. These requirements should be clear, actionable, measurable, and traceable to business requirements. Requirements should also define how the software should interact with humans, hardware, and other systems.

High-level design: The high-level design breaks the system’s architectural design into a less-abstracted view of sub-systems and modules and depicts their interaction with each other. This high-level design perspective focuses on how the system, along with all its components, implements in the form of modules. It recognizes the modular structure of each sub-system and their interaction among one another.

Detailed design: Detailed design involves the implementation of what is visible as a system and its sub-systems in a high-level design. This activity is more detailed towards modules and their implementations. It defines a logical structure of each module and their interfaces to communicate with other modules.

Software Architectural Interview Question

What Is Software Architecture?

The software architecture of a system depicts the system’s organization or structure, and provides an explanation of how it behaves. A system represents the collection of components that accomplish a specific function or set of functions. In other words, the software architecture provides a sturdy foundation on which software can be built.

A series of architecture decisions and trade-offs impact quality, performance, maintainability, and overall success of the system. Failing to consider common problems and long-term consequences can put your system at risk.

There are multiple high-level architecture patterns and principles commonly used in modern systems. These are often referred to as architectural styles. The architecture of a software system is rarely limited to a single architectural style. Instead, a combination of styles often make up the complete system.

What Are Four Methods That Are Commonly Used By Architects To Build Systems?

Normative, rational, argumentative, heuristic methodologies. The selection of the four methods depends on the circumstances of the project and a problem at hand. The first two methodologies are widely practiced in engineering institutions.

What Influences Architect’s Decisions?

Architect’s decisions are influenced by the system stakeholders, technical environment, problem domain area, organization’s intellectual assets, architect’s education and experience, and politics.

Advance Software Architectural Interview Question

Why Do You Need To Have Multiple Views To Accurately Describe System Architecture?

Each view has a specific goals and a purpose; each view accomplishes different objectives. Multiple views of a system provide an abstraction – a developer does not always need to see the whole system and all of its components. Additionally, different stakeholders need different views to understand their role in the system. This promotes understanding for all stakeholders and saves time, as some stakeholders may not care at all about someone else’s view. Finally, multiple views allow for a more concrete view. It is not possible to fit all components of the system on one sheet of paper and make clear sense of it.

What Are The Principles Of Good Architectural Documentation?

Statement of requirements establishes the problem boundary, puts the problem in perspective and explains why the work to be done makes sense. This is the most critical part of documentation as it gives a reader the perspective of a problem.
Description of context provides a list of inputs and outputs that will interact with a system at stake. Additionally, this description shows the interfaces of the external systems.
Use of architectural diagrams allows for improved communication and understanding of a system to be developed. The diagrams depict a developer’s imagination, and allow others to see how an original developer envisioned a system.
Consideration of implementation-level constraints prevents developers from fantasizing about a system that cannot be implemented. If a developer is working with a data-oriented repository style some of the implementation-level constraints may depend on hardware. Addressing these issues early build confidence among many stakeholders – to convince them that a system at stake is indeed possible.
Rationale for architectural design discusses different options and considerations that were entertained before a set architecture was chosen. Keeping a record of the rationale is important, as new employees or system maintainers will question the decisions later.

What Is The Essential Role Of A Software Architect?

Making the right decisions at the right time is the chief responsibility of a software architect. Specifically the architect must evaluate various design options in light of overall system objectives and constraints. Each architectural decision has its benefits and costs, and since it is not possible to achieve all quality attributes that one may desire, an architect must make tradeoffs between available options.

Software Architectural Interview Question

What Is The Difference Between Routine And Innovative Design?

Routine design aims at “solving familiar problems” and designing solutions by using the knowledge base from previous projects and experiences. For example, an accounting (payroll) system would most likely involve routine design; as such systems have been in production for a long time and are well understood. Routine design involves a lot of re-use and occurs much more frequently than an innovative design that requires original thinking. Innovative design is opposite of routine design, and aims at solving problems that do not have any previous knowledge base. Innovative design aims at solving original and unique problems, such as controlling an unmanned helicopter through a remote control center.

What Is An Open Proprietary Architectural Standard?

An open proprietary architectural standard is promoted by Morris and Ferguson who make case for open systems where the “complex of standards and rules” would be freely published. This open standard would allow anyone to see how the system was designed and constructed. This open-ended architecture would allow the software to evolve, because any enhancements to the software would have to adhere to a defined architectural, and freely available, standard. An example of an open proprietary product is the CCITT fax standard and the NTSC television standard. An example of a closed proprietary product is Adobe’s PDF file format and Windows 2000 OS, as no one but the company can make changes to the architecture.

What do you mean by Orchestration in software or cloud

Orchestration can be defined as the automation of configuration, coordination and management of computer applications, systems and services. Orchestration is a collection of steps that are executed to accomplish a complex task or to automate a process or workflow.
Cloud Orchestration helps to automate workflow processes and complex tasks that occur to deliver cloud resources as a service to achieve the desired goals. DevOps Orchestration refers to the automated management and coordination of develops practices to achieve defined goals.

Advance Software Architectural Interview Question

What are the OWASP top 10 security risks?

Broken Authentication
Injection
Expose Sensitive data
Broken Access control
XML External Entities (XXE)
Security mis-configurations
Cross Site Scripting (XSS)
Insecure De-serialization
Using Components with known vulnerabilities
Insufficient logging and monitoring

Explain some cloud components?

Components in cloud refers to many things like front end, back end, storage, network, servers, virtual machines, Data centers etc. Other components of cloud are applications which serve as a service. Examples of these services are Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS).

Explain Frequently used below Software Terms?

Usability
Readability
Maintainability
Flexibility
Testability
Reliability
Extensibility
Portability
Throughput
Security
ACID Guarantees
Concurrency

Software Architectural Interview Question

Discussion around different Software Architecture designs?

High Level Design (HLD) also known as system design or macro-level design.
Low Level Design (LLD) also known as detailed design or micro-level design.

Discussion around different Software Architecture diagram types?

Business Process flow diagrams
Functional diagrams

Explain some common Software Development Methodologies.

There are many widely adopted software development methodologies which will help you to decide which methodology is right for your team.

WATERFALL
FDD (FEATURE-DRIVEN DEVELOPMENT)
AGILE
SCRUM
XP (EXTREME PROGRAMMING)
LEAN
DEVOPS
RAPID APPLICATION DEVELOPMENT (RAD)

Advance Software Architectural Interview Question

What do you mean by Orchestration in software or cloud.

Explain commonly used below cloud terms.

Containerization
Virtualization
Latency
Fault tolerance
Elasticity
Scalability
Availability
Application Outage or Downtime
Resiliency
Data integrity
Data Redundancy

What is Dependency Injection?

In software engineering, dependency injection is a technique whereby one object supplies the dependencies of another object. A dependency is an object that can be used. An injection is the passing of a dependency to a dependent object that would use it. The service is made part of the client’s state. Dependency injection is also a creational design pattern.

Software Architectural Interview Question

What are acid transactions?

In computer science, ACID is a set of properties of database transactions intended to guarantee validity even in the event of errors, power failures, etc. In the context of databases, a sequence of database operations that satisfies the ACID properties is called a transaction.