Solution Architecture and Technology Selection

Introduction

A web application is more than a collection of screens and source files. It is a socio-technical system: users, business rules, data, infrastructure, security controls and operational practices must work together. Solution architecture describes how these elements are organised and how they communicate. Technology selection then converts architectural intentions into a practical stack of languages, frameworks, databases, hosting services and development tools.

Architecture is not a contest in which the newest approach always wins. A small internal application may be best served by a modular monolith, while a large platform with independent teams may justify microservices. The correct decision depends on requirements, constraints and expected change. This chapter compares common architectural approaches and presents a disciplined method for selecting a technology stack for a diploma-level web application project.

Learning Objectives

By the end of this chapter, you should be able to:

1. Compare monolithic, layered, component-based, RESTful, serverless and microservice approaches.
2. Distinguish an architectural style from an implementation technology.
3. Prepare context, component and data-flow diagrams.
4. Select a technology stack using cost, skills, scalability, security and maintainability criteria.
5. Explain architectural trade-offs and justify a design decision.
6. Apply these principles to a realistic web application case.

1. Architecture as a Set of Decisions

Software architecture establishes significant decisions that are difficult or expensive to reverse. These decisions include the boundaries of modules, communication protocols, data ownership, deployment units, authentication arrangements and operational responsibilities. Architecture should therefore be based on explicit quality attributes rather than personal preference.

Functional requirements describe what a system does: registering users, searching products or processing payments. Quality attributes describe how well it does it: response time, availability, security, usability, portability and ease of change. A useful architecture connects both categories.

A solution architect commonly asks:

• Who are the users and external systems?
• What are the system's most important business capabilities?
• Which data must be shared, protected or retained?
• What level of traffic and growth is expected?
• Which failures are acceptable, and how should the system recover?
• What skills, budget and operational capacity are available?

Architecture should also be documented. A short decision record can state the decision, context, alternatives considered, selected option and consequences. This prevents later confusion and makes design review possible.

2. Architectural Styles and Patterns

An architectural style is a general arrangement of responsibilities and communication. A pattern is a reusable solution to a recurring design problem. A technology, such as Node.js, Django or PostgreSQL, is an implementation choice. These categories should not be confused: REST is an architectural style for networked resources, whereas PostgreSQL is a database technology.

2.1 Monolithic Architecture

In a monolith, the application is deployed as one unit. Its user interface, business logic and data-access code may exist in the same codebase and process. A monolith can still be internally modular; “monolithic” primarily describes the deployment boundary.

Advantages include simple deployment, straightforward local development, low infrastructure cost and easy transactions within one database. These benefits are valuable for student projects, prototypes and small teams.

Disadvantages arise when the application becomes large. A change to one area may require redeploying the whole system. Components may become tightly coupled, and a failure or resource-intensive operation can affect the entire application. Independent scaling is also limited.

A well-structured modular monolith is often a sound starting point. It can establish clear domain boundaries before the complexity of distributed deployment is introduced.

2.2 Layered Architecture

Layering organises responsibilities vertically. A common web arrangement is:

• Presentation layer: HTTP routes, controllers, views and input handling.
• Application or service layer: use cases and orchestration.
• Domain layer: business rules and domain objects.
• Infrastructure or data-access layer: databases, files, email and external APIs.

A request normally moves from the presentation layer towards the data layer, while results return in the opposite direction. The dependency rule should be explicit. For example, domain logic should not depend directly on a web framework or database driver.

Layering improves comprehension, testing and replacement of infrastructure. However, excessive layers can produce pass-through classes with little value. Layering also does not automatically create independent deployability; a layered system can still be a monolith.

2.3 Component-Based Architecture

A component is a cohesive unit with a defined responsibility and interface. Components may be user-interface components, application modules or deployable services. Component-based design emphasises high cohesion within a component and low coupling between components.

For example, a learning platform might contain enrolment, course catalogue, assessment and notification components. Each component should expose deliberate operations rather than allowing other parts of the system to manipulate its internal data freely.

Component boundaries should follow business capabilities and likely sources of change. They should not be created merely because a class is large. Clear interfaces, dependency inversion and automated tests support component independence.

2.4 RESTful Architecture

REST, or Representational State Transfer, is a style for networked systems. Its important constraints include client–server separation, stateless requests, cacheable responses where appropriate, a uniform interface and a layered system. Resources are identified by URLs and manipulated using standard HTTP semantics.

Typical operations include GET for retrieval, POST for creation or processing, PUT for replacement, PATCH for partial modification and DELETE for removal. HTTP status codes communicate broad outcomes, but an API should also define a consistent error representation.

REST does not mean “return JSON from every endpoint.” A well-designed API considers resource naming, validation, pagination, filtering, versioning, authentication, idempotency and error handling. Statelessness means that each request contains the information needed for processing; it does not mean that the system cannot use a database or session store.

REST is often combined with a monolith or microservices. It therefore describes communication and interface style, not the entire deployment architecture.

2.5 Serverless Architecture

In serverless computing, the cloud provider manages server provisioning, operating-system maintenance and much of the scaling infrastructure. Developers deploy functions, event handlers or managed services. The application may respond to HTTP requests, queues, file uploads or scheduled events.

Benefits include low initial operational effort, automatic scaling for suitable workloads and payment models based on use. Limitations include cold-start latency, provider-specific interfaces, execution-time limits, distributed debugging and potentially unpredictable costs at high volume. Security configuration remains the developer's responsibility; serverless does not mean security-free.

Serverless is appropriate for sporadic workloads, background processing, file transformation and small APIs. It is less attractive when a workload requires long-running processes, highly predictable latency or extensive control over the runtime.

2.6 Microservice Architecture

Microservices divide an application into independently deployable services aligned with business capabilities. Each service ideally owns its data and communicates through APIs or asynchronous messaging.

Advantages include independent deployment, technology flexibility, independent scaling and organisational autonomy. These advantages become meaningful for sufficiently large systems and teams.

The costs are substantial: network failure, eventual consistency, distributed tracing, service discovery, deployment automation, versioned contracts and more complicated testing. A microservice architecture can also distribute a monolith's coupling across a network without removing it. Microservices should therefore be adopted because a genuine organisational or scaling problem requires them, not because they appear sophisticated.

Comparison of Approaches

These approaches are not mutually exclusive. A system may be a layered modular monolith exposing RESTful endpoints and using serverless image processing.

3. Architecture Diagrams

Diagrams are reasoning tools, not decoration. They should have a stated scope, legend where necessary and labels that correspond to actual responsibilities.

3.1 Context Diagram

A context diagram shows the system as one box and its relationships with external actors or systems. It answers: who interacts with the system, and what information crosses the boundary? It deliberately omits internal classes and database tables.

Figure: A context diagram identifies system boundaries and external interactions.

3.2 Component Diagram

A component diagram reveals internal building blocks and their interfaces. For a modest application, components may be modules within one deployment unit. A useful diagram identifies dependencies without showing every implementation class.

A component should have a clear responsibility. For example, an enrolment component may validate eligibility, create an enrolment record and publish an enrolment event. It should not also contain unrelated email formatting and payment-provider code.

3.3 Data-Flow Diagram

A data-flow diagram focuses on movement and transformation of data. It identifies external entities, processes, data stores and flows. A level-0 diagram can show the major processes; lower-level diagrams expand one process. Data-flow diagrams are especially useful for privacy analysis because they expose where personal or sensitive data travels.

When drawing one, label flows with nouns such as “enrolment details” or “payment confirmation,” distinguish data stores from processes, and ensure every external input and output has a logical destination.

4. Selecting a Technology Stack

A stack should be selected through criteria rather than fashion. A practical evaluation matrix gives each criterion a weight and each candidate a score. For candidate j, a weighted score can be calculated as:

Here, S_j is the normalised score for candidate j, w_i is the importance weight of criterion i, and r_ij is the candidate's rating for that criterion. Ratings must use a defined scale, such as 1 (poor) to 5 (excellent); weights should be non-negative. The calculation is meaningful only when criteria and rating definitions are consistent. It supports judgement; it does not replace it.

Relevant criteria include:

• Cost: hosting, licences, databases, observability and staff time.
• Skills: existing team competence, learning curve and hiring availability.
• Scalability: ability to handle growth in users, data and traffic.
• Security: authentication support, patching, secrets management, isolation and auditability.
• Maintainability: readability, testing, documentation, upgrade path and operational simplicity.
• Delivery fit: community support, deployment automation and compatibility with requirements.

A low-cost technology can become expensive if it increases debugging time or security risk. Conversely, a highly scalable service can be wasteful for a small application. Total cost of ownership includes both direct expenditure and engineering effort.

Illustrative Selection Matrix

Suppose a student team compares three backend options for a course platform. The team assigns weights that sum to 100 and scores each option from 1 to 5.

The weighted result for Framework A is (20×5 + 25×4 + 20×4 + 15×4 + 20×4) ÷ 100 = 4.20. Framework B produces 4.20 as well, while Framework C produces 3.80. The tie does not mean the two options are identical. The team should examine which criteria are uncertain, run a small prototype and consider operational constraints. A decision record might select Framework B because existing skills reduce delivery risk.

5. Security, Governance and Maintainability

Security must influence architecture from the beginning. Apply least privilege: each user, service and database account receives only the permissions needed for its function. Validate input at trust boundaries, encode output appropriately, protect credentials in a secrets manager, use encrypted transport, log security-relevant events and keep dependencies patched.

Authentication establishes identity; authorisation determines permitted actions. These should not be treated as the same concern. A role-based policy may permit instructors to edit their own courses while preventing them from viewing another instructor's private data.

Privacy requires data minimisation, purpose limitation, retention rules and controlled access. Personal data should not be copied into development environments without a defensible reason and appropriate protection. Depending on jurisdiction, data-protection laws may impose rights concerning access, correction, deletion and breach management.

Maintainability is supported by small cohesive modules, automated tests, continuous integration, code review, consistent error handling, documentation and observable deployments. Observability normally combines logs, metrics and traces. Logs should avoid passwords, tokens and unnecessary personal data.

6. Applied Case: CourseConnect

The following is an illustrative case developed for learning purposes.

Background and Problem

A training institute wants CourseConnect, a web application through which learners browse courses, enrol, pay online and receive notifications. Instructors publish course information and view enrolments. The institute has four developers, limited operations experience and a modest initial user population, but it expects seasonal registration peaks.

The application must protect personal and payment-related information, support mobile browsers and remain affordable. The institute also wants a future mobile application to use the same backend.

Analysis

The system has several capabilities: identity and access management, course catalogue, enrolment, payment coordination and notifications. Payment-card details should not be stored by CourseConnect; a payment provider's hosted or tokenised service should be used. Notifications may be processed asynchronously so that a slow email provider does not delay enrolment confirmation.

A microservice design would provide independent deployment, but it would also require service operations, distributed tracing and complex consistency handling beyond the team's current capacity. A pure serverless design could reduce administration, but provider-specific configuration and debugging may increase learning and operational risk.

Approach and Solution

The recommended first release is a layered modular monolith exposing a RESTful API. Modules are organised around identity, catalogue, enrolment, payments and notifications. A relational database is selected because enrolment and payment records require constraints and transactional consistency. A managed object store may hold course images, while a queue and serverless worker handle notification jobs.

The web client communicates with the API over HTTPS. The API validates requests, applies authorisation and invokes application services. The database stores transactional records. The payment provider returns a token or payment status rather than exposing card data to the application. A background worker consumes notification events and records delivery outcomes.

This design keeps the core system simple while leaving explicit seams for later extraction. If notification volume grows, that worker can scale independently. If a genuine team or scaling boundary emerges, a carefully defined module can become a service.

Outcome and Learning Points

The architecture meets current needs with manageable cost and complexity. It supports a future mobile client through the API, reduces payment-data exposure and permits asynchronous processing. Its main limitation is that the central application remains a shared deployment unit. The team should monitor response times, error rates, database load and deployment frequency before considering decomposition.

The case demonstrates a central principle: architecture should be proportionate to risk and organisational capability. “Start modular, measure, and evolve” is often more responsible than adopting distributed systems prematurely.

7. Common Challenges and Contemporary Developments

Architecture decisions are uncertain because requirements change and estimates are imperfect. Teams may also confuse scalability with performance. Scalability concerns how capacity changes as demand grows; performance concerns the behaviour of a system under a given load. Caching can improve response time but introduce stale data. Replication can improve availability but complicate consistency.

Containers and managed cloud platforms can standardise deployment, but they do not remove the need for architecture. Infrastructure-as-code makes environments reproducible, while continuous delivery reduces manual release risk. Platform engineering increasingly provides reusable deployment and observability capabilities to development teams.

AI-assisted coding can accelerate scaffolding and test generation, but generated code must be reviewed for insecure dependencies, licensing concerns, hallucinated APIs and inadequate error handling. Confidential source code and personal data should not be submitted to tools without organisational approval. Human accountability for architecture, security and compliance remains essential.

Best-Practice Checklist

Before approving a solution architecture, confirm that:

1. System scope and external actors are documented.
2. Major components have clear responsibilities and interfaces.
3. Data stores, sensitive data and data flows are identified.
4. Architecture matches team skills, budget and operational capacity.
5. Authentication, authorisation, secrets and audit requirements are addressed.
6. Failure handling, backups and recovery expectations are defined.
7. Technology choices have explicit evaluation criteria.
8. A prototype has tested the riskiest assumption.
9. Monitoring and maintenance responsibilities are assigned.
10. Decisions and trade-offs are recorded for future review.

Chapter Summary

Solution architecture connects requirements to system structure, interfaces, data movement and deployment decisions. Monolithic, layered, component-based, RESTful, serverless and microservice approaches solve different problems and may be combined. Layered modular monoliths are often appropriate for small teams, while microservices require strong justification because they introduce distributed-system complexity. Context diagrams show external relationships, component diagrams show internal responsibilities, and data-flow diagrams show how information is transformed and stored. Technology selection should evaluate cost, skills, scalability, security, maintainability and operational fit. A disciplined architecture is proportionate, documented, testable and capable of evolving.

Key Terms

Architecture: Significant structural and behavioural decisions governing a software system.

Architectural style: A recurring way of organising system elements and communication.

Monolith: An application deployed as one operational unit.

Layered architecture: Organisation into presentation, application, domain and infrastructure responsibilities.

Component: A cohesive unit with a defined responsibility and interface.

REST: A networked architectural style based on resources and uniform HTTP interaction.

Serverless: A model in which the provider manages much of the server infrastructure.

Microservice: An independently deployable service aligned with a business capability.

Coupling: The degree of dependency between software units.

Cohesion: The degree to which a unit's responsibilities belong together.

Context diagram: A diagram showing a system and its external entities.

Component diagram: A diagram showing internal components and their dependencies.

Data-flow diagram: A diagram showing data sources, transformations, stores and destinations.

Quality attribute: A non-functional property such as security, availability or maintainability.

Scalability: The ability to accommodate increased demand by adding or adjusting capacity.

Idempotency: The property that repeating an operation has the same intended effect as performing it once.

Least privilege: Granting only the permissions required for an activity.

Observability: The ability to understand internal system behaviour through outputs such as logs, metrics and traces.

Technical debt: Future cost created by expedient or poorly understood technical decisions.

Technology stack: The collection of technologies used to build and operate an application.

Review Questions

Short Answer Questions

1. What is the difference between an architectural style and a technology?
2. State two advantages and two disadvantages of a monolithic architecture.
3. What information is normally shown in a context diagram?
4. Distinguish authentication from authorisation.
5. Why should a technology-selection matrix define its rating scale?

Long Answer Questions

1. Compare layered architecture with component-based architecture and explain how they can coexist.
2. Explain the benefits and costs of adopting microservices for a growing web application.
3. Describe REST constraints and discuss common design concerns in a RESTful API.
4. Explain how security and privacy should influence architecture from requirements through deployment.
5. Develop a justified technology-selection process for a small web application team.

Analytical / Application Questions

1. A three-person team is building a local library application with moderate traffic and a single relational database. Recommend an architecture and justify it using cost, skills and maintainability.
2. Draw a context diagram and a level-0 data-flow diagram for an online food-ordering system. Identify sensitive data and external services.
3. A notification module is slowing down the main application during peak registration. Should it become a microservice, a serverless function, or a background worker within the existing application? Evaluate the alternatives and state what evidence you would collect before deciding.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a monolithic application?

A. Every function is deployed as an independent service

B. The application is deployed as one operational unit

C. It cannot contain internal modules

D. It must use serverless computing

Correct Answer: B. The application is deployed as one operational unit

Question 2

Which diagram focuses primarily on external actors and systems?

A. Context diagram

B. Class diagram

C. Sequence diagram

D. Deployment diagram

Correct Answer: A. Context diagram

Question 3

What is a major operational cost of microservices?

A. They cannot expose APIs

B. They eliminate network failures

C. They introduce distributed-system complexity

D. They require a single shared database

Correct Answer: C. They introduce distributed-system complexity

Question 4

In a layered application, business rules should normally be concentrated in the:

A. Presentation layer

B. Domain or application layers

C. Web browser cache

D. CSS layer

Correct Answer: B. Domain or application layers

Question 5

Which criterion concerns the ability to handle increased demand?

A. Scalability

B. Colour consistency

C. Source-code indentation

D. Licensing vocabulary

Correct Answer: A. Scalability

Question 6

What does least privilege mean?

A. All users receive administrator access

B. Permissions are granted only as needed

C. Passwords are never changed

D. Data is stored without encryption

Correct Answer: B. Permissions are granted only as needed

Question 7

Which statement about REST is correct?

A. REST is a database engine

B. REST requires every system to be a microservice

C. REST is an architectural style for networked systems

D. REST prohibits HTTP status codes

Correct Answer: C. REST is an architectural style for networked systems

Question 8

Using the stated weighted-score formula, a candidate with a weighted total of 420 across weights totalling 100 receives what score?

A. 0.42

B. 4.20

C. 42.0

D. 4200

Correct Answer: B. 4.20

Question 9

Why might a relational database be selected for enrolment records?

A. It guarantees zero network latency

B. It supports constraints and transactional consistency

C. It removes the need for authentication

D. It automatically designs all user interfaces

Correct Answer: B. It supports constraints and transactional consistency

Question 10

What is a responsible reason to delay adopting microservices?

A. The team has no business capabilities

B. The system has no source code

C. The operational complexity is not justified by current needs

D. The application uses HTTPS

Correct Answer: C. The operational complexity is not justified by current needs