robby Flashcards

(65 cards)

1
Q

A traditional and straightforward
architectural style where all components of
an application are tightly integrated into a
single codebase and deployed as a single
unit.

A

MONOLITHIC ARCHITECTURE

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

CHARACTERISTICS OF
MONOLITHIC ARCHITECTURE

A

SINGLE CODEBASE
TIGHT COUPLING
SCALABILITY LIMITATION
LIMITED FLEXIBILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

The entire application is built as a single
codebase.

A

SINGLE CODEBASE

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Components within the application are
closely interconnected.

A

TIGHT COUPLING

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Scaling can be challenging because all
components are part of a single unit.

A

SCALABILITY LIMITATION

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Making changes or updates to specific
components may require redeploying the
entire application.

A

LIMITED FLEXIBILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

An approach where an application is broken
down into small, independently deployable
services, each focused on a specific business
capability.

A

MICROSERIVES ARCHITECTURE

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

CHARACTERISTICS OF
MICROSERVICES ARCHITECTURE

A

DECENTRALIZATION
SCALABILITY
INDEPENDENCE
FLEXIBILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Services can be developed and deployed
independently, enabling faster development
and scaling of specific components.

A

INDEPENDENCE

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

The application is divided into multiple
services.

A

DECENTRALIZATION

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Allows for fine-grained scalability.

A

SCALABILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Changes or updates to one service do not
affect the entire application.

A

FLEXIBILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

An approach where components of a system
communicate by generating and responding
to events.

A

EVENT-DRIVEN ARCHITECTURE

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

CHARACTERISTICS OF
EVENT-DRIVEN ARCHITECTURE

A

EVENT GENERATION
ASYNCHRONOUS
SCALABILITY
FLEXIBILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Components generate events when certain
conditions or actions occur.

A

EVENT GENERATION

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Communication between components is
asynchronous.

A

ASYNCHRONOUS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Event-driven systems can scale horizontally
to handle increased event processing.

A

SCALABILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

New components can be added or removed
without significant disruption.

A

FLEXIBILITY

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

A non-technical definition of something that
is required from the system.

A

SYSTEM REQUIREMENTS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Functional requirements are requirements
which pertain to the function of the system.

A

FUNCTIONAL REQUIREMENTS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Non-Functional requirements are
requirements that cover areas that don’t
directly affect the function of the system.

A

NON-FUNCTIONAL REQUIREMENTS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

A technical definition of what is required
from the system.

A

SYSTEM SPECIFICATION

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

SYSTEM SPECIFICATION

A

API ENDPOINTS AND METHODS
REQUEST AND RESPONSE FORMATS
AUTHENTICATION AND AUTHORIZATION
RATE LIMITING

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Define the available endpoints (URLs) and
HTTP methods (GET, POST, PUT, DELETE)
supported by the API.

A

API ENDPOINTS AND METHODS

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Specify the data formats that the API accepts in requests and the formats it returns in responses.
REQUEST AND RESPONSE FORMATS
26
Detail how users or clients authenticate themselves to access the API and the permissions required for different endpoints.
AUTHENTICATION AND AUTHORIZATION
27
Describe rate limiting rules to prevent abuse or excessive use of the API.
RATE LIMITING
28
System design is critical in software development because it serves as a blueprint for building software systems.
IMPORTANCE OF SYSTEM DESIGN IN SOFTWARE DEVELOPMENT
29
IMPORTANCE OF SYSTEM DESIGN IN SOFTWARE DEVELOPMENT
BLUEPRINT FOR DEVELOPMENT EARLY DETECTION ISSUES SCALABILITY AND MAINTENANCE
30
System design provides a detailed plan that developers must follow during the implementation phase.
BLUEPRINT FOR DEVELOPMENT
31
A well-designed system is easier to scale and maintain.
SCALABILITY AND MAINTENANCE
32
Many possible problems may be recognized and corrected during the design phase.
EARLY DETECTION ISSUES
33
SOLID represents five fundamental design principles for object- oriented programming, which help developers create flexible and maintainable code.
KEY DESIGN PRINCIPLES (SOLID PRINCIPLES)
34
SOLID PRINCIPLES
Single Responsibility Principle (SRP) Open/Closed Principle (OCP) Liskov Substitution Principle (LSP) Interface Segregation Principle (ISP) Dependency Inversion Principle
35
A class should have only one reason to change. It should have a single, well-defined responsibility. When a class has multiple responsibilities, changes to one can impact others.
Single Responsibility Principle (SRP)
36
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.
Open/Closed Principle (OCP)
37
Subtypes must be substitutable for their base types without altering the correctness of the program.
Liskov Substitution Principle (LSP)
38
Client-specific interfaces are better than one general-purpose interface. Clients should not be forced to implement a function they do not need.
Interface Segregation Principle (ISP)
39
This principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes and functions.
Dependency Inversion Principle
40
the process of combining different computing systems and software applications to act as a coordinated whole.
SYSTEM INTEGRATION?
41
the high-level structure and design of a computing system, including its components and their interactions.
SYSTEM ARCHITECTURE?
42
KEY COMPONENTS OF SYSTEM ARCHITECTURE IN AN API
APPLICATION LAYER API GATEWAY DATA LAYER MIDDLEWARE AUTHENTICATION AND AUTHORIZATION LOAD BALANCERS MONITORING AND ANALYTICS VERSIONING AND DOCUMENTATION
43
This is where the API resides, and it serves as the interface between different software applications.
APPLICATION LAYER
44
It is a component that manages, secures, and routes API requests.
API GATEWAY
45
This layer stores and manages the data that APIs interact with.
DATA LAYER
46
facilitate communication and interaction between various parts of a system, including APIs.
MIDDLEWARE
47
verifies the identity of the requester, while authorization determines what actions they are allowed to perform.
AUTHENTICATION AND AUTHORIZATION
48
These aspects of system architecture ensure that APIs can handle increased load and remain available even in the face of failures.
SCALABILITY AND REDUNDANCY
49
The architecture should be capable of accommodating increased workloads or resource demands without significant changes.
SCALABILITY
50
involves breaking down a system into distinct, self-contained modules or components.
MODULARITY
51
ensures that a system consistently performs its intended functions accurately and without failures.
RELIABILITY
52
the ability of the architecture to adapt to changing requirements or new technologies without requiring a complete redesign.
FLEXIBILITY
53
focuses on the ease of managing and updating a system.
MAINTAINABILITY
54
should be an integral part of the architecture. This includes mechanisms for access control, encryption, authentication, and data protection.
SECURITY
55
ensures that the system can communicate and work seamlessly with other systems or components, especially when integrating with external services or APIs.
INTEROPERABILITY
56
Cost-effectiveness involves making efficient use of resources while achieving the desired functionality and performance.Cost-effectiveness involves making efficient use of resources while achieving the desired functionality and performance.
COST-EFFECTIVENESS
57
Performance considerations involve optimizing system speed, responsiveness, and resource utilization.considerations involve optimizing system speed, responsiveness, and resource utilization.
PERFORMANCE
58
This method allows for the server to find the data/resource you requested and sends it back to you.
GET
59
If you perform the ‘PUT’ request, then the server will update a resource in the database.
PUT
60
This method permits the server to create a new resource in the database.
POST
61
This method allows the server to delete a resource in the database.
DELETE
62
Structure of SOAP Message
SOAP Envelope Header Body
63
The root element in every SOAP message, and contains two child elements, an optional
element, and a mandatory element. It encapsulates all the data in a message and identifies the XML document
SOAP Envelope
64
It contains additional information about the SOAP message and is optional.
Header
65
This element is mandatory and includes the details of the actual message that need to be sent from the web service to the calling application. This data includes call and response information.
Body