robby Flashcards

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
Q

Specify the data formats that the API
accepts in requests and the formats it
returns in responses.

A

REQUEST AND RESPONSE FORMATS

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

Detail how users or clients authenticate
themselves to access the API and the
permissions required for different endpoints.

A

AUTHENTICATION AND AUTHORIZATION

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

Describe rate limiting rules to prevent abuse
or excessive use of the API.

A

RATE LIMITING

28
Q

System design is critical in software development
because it serves as a blueprint for building software
systems.

A

IMPORTANCE OF SYSTEM DESIGN
IN SOFTWARE DEVELOPMENT

29
Q

IMPORTANCE OF SYSTEM DESIGN
IN SOFTWARE DEVELOPMENT

A

BLUEPRINT FOR DEVELOPMENT
EARLY DETECTION ISSUES
SCALABILITY AND MAINTENANCE

30
Q

System design provides a detailed plan that
developers must follow during the
implementation phase.

A

BLUEPRINT FOR DEVELOPMENT

31
Q

A well-designed system is easier to scale and
maintain.

A

SCALABILITY AND MAINTENANCE

32
Q

Many possible problems may be recognized
and corrected during the design phase.

A

EARLY DETECTION ISSUES

33
Q

SOLID represents five fundamental design principles for object-
oriented programming, which help developers create flexible and

maintainable code.

A

KEY DESIGN PRINCIPLES
(SOLID PRINCIPLES)

34
Q

SOLID PRINCIPLES

A

Single Responsibility Principle (SRP)

Open/Closed Principle (OCP)

Liskov Substitution Principle (LSP)

Interface Segregation Principle (ISP)

Dependency Inversion Principle

35
Q

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.

A

Single Responsibility Principle (SRP)

36
Q

Software entities (classes, modules,
functions, etc.) should be open for extension
but closed for modification.

A

Open/Closed Principle (OCP)

37
Q

Subtypes must be substitutable for their
base types without altering the correctness
of the program.

A

Liskov Substitution Principle (LSP)

38
Q

Client-specific interfaces are better than
one general-purpose interface. Clients
should not be forced to implement a function
they do not need.

A

Interface Segregation Principle (ISP)

39
Q

This principle states that our classes should
depend upon interfaces or abstract classes
instead of concrete classes and functions.

A

Dependency Inversion Principle

40
Q

the process of combining
different computing systems and software
applications to act as a coordinated whole.

A

SYSTEM INTEGRATION?

41
Q

the high-level structure
and design of a computing system, including its
components and their interactions.

A

SYSTEM ARCHITECTURE?

42
Q

KEY COMPONENTS OF SYSTEM
ARCHITECTURE IN AN API

A

APPLICATION LAYER
API GATEWAY
DATA LAYER
MIDDLEWARE
AUTHENTICATION AND AUTHORIZATION
LOAD BALANCERS
MONITORING AND ANALYTICS
VERSIONING AND DOCUMENTATION

43
Q

This is where the API resides, and it serves as
the interface between different software
applications.

A

APPLICATION LAYER

44
Q

It is a component that manages, secures, and
routes API requests.

A

API GATEWAY

45
Q

This layer stores and manages the data that
APIs interact with.

A

DATA LAYER

46
Q

facilitate
communication and interaction between
various parts of a system, including APIs.

A

MIDDLEWARE

47
Q

verifies the identity of the
requester, while authorization determines
what actions they are allowed to perform.

A

AUTHENTICATION AND AUTHORIZATION

48
Q

These aspects of system architecture
ensure that APIs can handle increased load
and remain available even in the face of
failures.

A

SCALABILITY AND REDUNDANCY

49
Q

The architecture should be capable of
accommodating increased workloads or
resource demands without significant
changes.

A

SCALABILITY

50
Q

involves breaking down a system
into distinct, self-contained modules or
components.

A

MODULARITY

51
Q

ensures that a system
consistently performs its intended functions
accurately and without failures.

A

RELIABILITY

52
Q

the ability of the architecture to
adapt to changing requirements or new
technologies without requiring a complete
redesign.

A

FLEXIBILITY

53
Q

focuses on the ease of
managing and updating a system.

A

MAINTAINABILITY

54
Q

should be an integral part
of the architecture. This includes
mechanisms for access control, encryption,
authentication, and data protection.

A

SECURITY

55
Q

ensures that the system can
communicate and work seamlessly with
other systems or components, especially
when integrating with external services or
APIs.

A

INTEROPERABILITY

56
Q

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.

A

COST-EFFECTIVENESS

57
Q

Performance considerations involve
optimizing system speed, responsiveness,
and resource utilization.considerations involve
optimizing system speed, responsiveness,
and resource utilization.

A

PERFORMANCE

58
Q

This method allows for the server to find the data/resource you requested
and sends it back to you.

A

GET

59
Q

If you perform the ‘PUT’ request, then the server will update a resource in
the database.

A

PUT

60
Q

This method permits the server to create a new resource in the database.

A

POST

61
Q

This method allows the server to delete a resource in the database.

A

DELETE

62
Q

Structure of SOAP Message

A

SOAP Envelope
Header
Body

63
Q

The root element in every SOAP message, and contains two
child elements, an optional <Header> element, and a mandatory <Body> element.
It encapsulates all the data in a message and identifies the XML document

A

SOAP Envelope

64
Q

It contains additional information about the SOAP message and is
optional.

A

Header

65
Q

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.

A

Body