1
Q
What are architecture drivers?
A
Drivers provide the architect with data that allows them to decide which solution to use in a given project.
- How long will the project take to develop?
- What is the team’s experience?
- Is the application for a single platform or multiple platforms?
- How large is the team?
2
Q
What are microfrontends architecture?
A
3
Q
Main reasons to use microfrontends
A
4
Q
Microfrontend question:
A
5
Q
What is microfrontend bult-time integration?
A
6
Q
What is microfrontend run-time integration?
A
7
Q
What are pros and cons of microfrontend run-time integration?
A
8
Q
What are pros and cons of microfrontend bult-time integration?
A
9
Q
What is the job of webpack bundlers?
A
Its job is to combine many files that our project rely on and create output file with all the code with working application.
10
Q
What is a different name for island architecture?
A
Partial or selective hydration.
11
Q
What is frontend island architecture?
A
Island architecture is a modern frontend pattern that optimizes web performance by combining server-rendered static content with selective client-side interactivity. It offers a middle ground between traditional static sites and client-heavy single-page applications (SPAs).
12
Q
True or False: Frontend island architecture can lead to increased load times due to multiple independent components.
A
True
13
Q
What is a common challenge of implementing frontend island architecture?
A
Managing the complexity of multiple independent components and ensuring they work seamlessly together.
14
Q
What technology is often used to implement frontend island architecture?
A
JavaScript frameworks such as Astro, React, Vue, or Angular are commonly used.
15
Q
Microfrontend vs Island Architecture
A
While both patterns encourage modularity, islands architecture focuses on mixing static and dynamic content at a component level within pages, rather than splitting the entire frontend codebase into separate deployable apps like micro-frontends.
16
Q
How Island Architecture works from server render to seeing the page by user?
A
Initial Server Render: The server generates the HTML for the whole page, including all static and interactive islands.
Static Content Delivered: The browser displays the static content instantly—this is the majority of the page, SEO-friendly and extremely fast.
Hydration of Islands: Only the code for interactive widgets is loaded on the client, and these widgets “hydrate”
17
Q
What will the user with disabled js in browser see in app made with island architecture?
A
static content, without interactive islands
18
Q
What is “hydration?
A
Hydration is the process where static server-rendered HTML is enhanced on the client with JavaScript to become interactive.
19
Q
Why do we try to use mount function utility instead of passing react component from marketing to container?
A
Because this is a technical coupling. We assume that Container and Marketing will be always a React apps which is incorrect.
20
Q
Architektura oprogramowania to rzeczy które trudno zmienić, czyje to słowa ?
A
Martin Fowler
21
Q
Are architectural decisions binary (either architectural or not)?
A
No. Decisions exist on a spectrum from tactical to strategic, with most landing somewhere in between.
Understanding this spectrum helps in identifying the nature of decisions made in software architecture.
22
Q
Why does it matter if a decision is architectural?
A
It determines when to involve architects, how much discussion is needed, and what review process is appropriate.
This ensures that significant decisions are made with the right level of oversight.
23
Q
What are the 3 spectrums for evaluating decisions?
A
- Strategic vs Tactical
- Required effort/work
- Significance of tradeoffs
These spectrums help categorize decisions based on their impact and complexity.
24
Q
What characterizes a strategic decision?
A
- Long-term impact
- Affects multiple teams/components
- Sets constraints for future decisions
- Expensive to reverse
Strategic decisions shape the overall direction and architecture of a system.
25
Give an example of a **strategic decision**.
Choosing microservices vs. monolith architecture.
## Footnote
This decision affects the entire system's structure and future scalability.
26
What characterizes a **tactical decision**?
* Short-term
* Affects single feature/component
* Localized impact
* Relatively easy to change later
## Footnote
Tactical decisions are often more focused and less impactful on the overall architecture.
27
Give an example of a **tactical decision**.
Choosing a specific notification library like react-toastify vs. sonner.
## Footnote
This decision is specific to a feature and can be changed without major repercussions.
28
What defines a **high-effort decision**?
* Touches many parts of codebase
* Requires team coordination
* Needs extensive testing/migration
* Takes weeks or months
## Footnote
High-effort decisions often require significant resources and planning.
29
Give an example of a **high-effort decision**.
Adopting a new database technology (switching from PostgreSQL to MongoDB).
## Footnote
This involves extensive changes across the system and careful planning.
30
Give an example of a **low-effort decision**.
Changing a UI color scheme from blue to green.
## Footnote
Low-effort decisions can be made quickly and typically have minimal impact.
31
What is the most important spectrum for identifying **architectural decisions**?
Whether the decision involves significant tradeoffs between competing quality attributes.
## Footnote
This helps in understanding the implications of the decision on system quality.
32
What tradeoffs exist between **synchronous** and **asynchronous communication**?
* Sync is simpler but can’t handle real-time well
* Async enables real-time but is more complex to implement and scale
## Footnote
Understanding these tradeoffs is crucial for designing effective communication patterns.
33
Give an example of a decision **WITHOUT significant tradeoffs**.
Whether to separate List and ListItem components or combine them - both approaches work fine with minimal differences.
## Footnote
Such decisions can be made with less deliberation as they do not significantly impact the system.
34
What tradeoffs come with implementing **optimistic updates**?
* Better UX and perceived performance
* More complex error handling and state synchronization challenges
## Footnote
These tradeoffs must be considered when designing user interactions.
35
What should you do with **“in-between” decisions**?
* Discuss with architects
* Document tradeoffs (ADR)
* Get team alignment
* Review later
## Footnote
This process ensures that all perspectives are considered and documented.
36
Should architects be involved in **all decisions**?
No, but they should be consulted on decisions with significant tradeoffs or strategic implications, even if just briefly.
## Footnote
This helps maintain architectural integrity without overburdening the process.
37
Can **tactical decisions** become **strategic**?
Yes, when they accumulate. For example, using 15 different notification libraries creates a strategic mess from tactical decisions.
## Footnote
This highlights the importance of monitoring tactical choices.
38
Is **high effort** the same as **architectural importance**?
No. Some low-effort decisions have huge consequences. Some high-effort tasks are tedious but not architectural.
## Footnote
This distinction is crucial for prioritizing decision-making.
39
What are the **4 dimensions** of software architecture?
* Architectural Characteristics
* Architectural Decisions
* Logical Components
* Architectural Style
## Footnote
These dimensions provide a framework for understanding and analyzing software architecture.
40
What are **architectural characteristics**?
Quality attributes describing how a system should behave (performance, scalability, security, maintainability).
## Footnote
These characteristics guide the design and implementation of the system.
41
Why do **architectural characteristics** matter?
Ignoring them causes systems to fail in production under real-world conditions despite working in development.
## Footnote
This emphasizes the need for careful consideration of these attributes.
42
What are **architectural decisions**?
Rules, guidelines, and constraints that govern how developers build and modify the system.
## Footnote
These decisions shape the overall architecture and functionality of the system.
43
Give an example of an **architectural decision**.
“All data must be encrypted at rest” or “Use WebSocket for real-time updates.”
## Footnote
Such decisions have far-reaching implications for system security and performance.
44
What are **logical components**?
High-level building blocks that encapsulate specific functionality (e.g., User Management, Payment Processing).
## Footnote
These components help organize the system's functionality.
45
What makes a good **logical component**?
* Single clear purpose
* Minimal dependencies
* Hidden implementation details
* Independently testable
## Footnote
These qualities enhance the maintainability and clarity of the system.
46
What is **architectural style**?
The overall structure and organization pattern of a system (e.g., microservices, layered, event-driven).
## Footnote
Architectural style influences how components interact and are organized.
47
Name **4 common architectural styles**.
* Layered
* Microservices
* Event-Driven
* Modular Monolith
## Footnote
Each style has its own advantages and tradeoffs.
48
How do **characteristics influence decisions**?
Desired characteristics drive decisions (e.g., need security → decision to encrypt all data).
## Footnote
This relationship highlights the importance of aligning decisions with system goals.
49
How do **decisions influence components**?
Decisions shape component structure (e.g., single responsibility principle → break monolith into modules).
## Footnote
This illustrates how architectural choices affect the design of components.
50
How do **components shape style**?
Component organization determines architectural style (e.g., independent components → microservices).
## Footnote
This connection is vital for understanding how design choices impact architecture.
51
How does **style enable characteristics**?
Architectural style supports specific characteristics (e.g., microservices → better scalability).
## Footnote
This relationship is crucial for achieving desired system behaviors.
52
What happens without clear **component boundaries**?
You get a “big ball of mud” - tangled code where changes break things and testing is difficult.
## Footnote
This emphasizes the importance of clear design principles.
53
What happens without explicit **architectural decisions**?
Inconsistency, technical debt, and systems that are hard to maintain.
## Footnote
This highlights the necessity of making informed architectural choices.
54
Do all **characteristics matter equally** for every system?
No. Identify the most critical characteristics based on your specific business requirements and user needs.
## Footnote
This ensures that the architecture aligns with the goals of the project.
55
What is **software architecture** according to Martin Fowler?
“The important stuff. The stuff that matters. The stuff that’s hard to change.”
## Footnote
Architecture represents foundational decisions that are costly to modify later.
56
What’s the difference between **architectural decisions** and **implementation details** in frontend development?
Architectural decisions are hard-to-change choices that affect the entire system (e.g., SPA vs. SSR). Implementation details are easier-to-change choices (e.g., React vs. Vue).
## Footnote
Good abstractions allow for swapping implementation details without redesigning the architecture.
57
Give an example of **architectural decision** using house building analogy.
In house architecture, the foundation, walls, and roof are architectural decisions - hard and expensive to change. The color of walls, furniture, and decorations are implementation details - easy to change later.
## Footnote
This analogy helps clarify the distinction between architectural and implementation choices.
58
What is the main **CSS problem** in microfrontends?
CSS styles are global by default, so styles from one microfrontend can unintentionally override or leak into others when loaded on the same page, causing unexpected UI issues like style collisions.
## Footnote
This issue arises because CSS selectors apply globally, leading to conflicts.
59
Give an example of **CSS conflict** in microfrontends.
Team A: .button { color: blue; padding: 10px; }. Team B (loaded after): .button { color: red; }. Result: All buttons turn red, breaking Team A's UI due to global selector specificity and load order.
## Footnote
This illustrates how the order of CSS loading can affect the final rendered styles.
60
How do **CSS Modules** solve CSS issues in microfrontends?
CSS Modules scope styles locally by hashing class names at build-time (e.g., .button becomes .button__abc123), preventing global leaks while keeping CSS syntax intact—no runtime overhead.
## Footnote
This technique allows for modular and reusable styles without conflicts.
61
What is **Shadow DOM** and how does it help microfrontends?
Shadow DOM creates an isolated DOM subtree per microfrontend, encapsulating its CSS so selectors don't affect outside elements (or vice versa), providing true style isolation like web components.
## Footnote
This encapsulation ensures that styles and scripts do not interfere with each other across microfrontends.
62
Name techniques to isolate **CSS** in microfrontends.
- Prefix selectors (e.g., PostCSS Prefixwrap: #mfe1 .button)
- CSS-in-JS (Emotion/Styled Components) with unique hashes
- Utility classes (Tailwind)
- BEM naming conventions
## Footnote
These methods provide various approaches to prevent CSS conflicts and ensure style encapsulation.
63
Why configure **random class names** in CSS-in-JS for MFEs?
Default hashes are predictable (content/file-based), causing collisions across MFEs; true randomness ensures unique, non-leaking selectors.
## Footnote
This practice helps maintain style encapsulation and prevents unintended style overrides.
64
What does horizontal scaling mean vs. vertical scaling?
**Horizontal**: add more machines (scale out) — better for fault tolerance. **Vertical**: upgrade existing machine (more CPU/RAM) — simpler but has limits.
65
What is the CAP theorem?
A distributed system can guarantee at most **2 of 3**: **C**onsistency (all nodes see same data), **A**vailability (every request gets a response), **P**artition tolerance.
66
In the CAP theorem, which property must always be chosen?
**Partition tolerance** — network partitions will happen. Real choice is between **CP** (consistent but may reject requests) and **AP** (available but may return stale data).
67
What is load balancing?
Distributing incoming traffic across multiple servers to prevent any single server from being overwhelmed. Common strategies: round-robin, least connections, IP hash.
68
What are caching strategies in distributed systems?
**CDN** (static assets at edge), **in-memory cache** (Redis/Memcached for hot data), **browser cache** (HTTP headers), **write-through/write-back** patterns.
69
What is cache invalidation and why is it hard?
Keeping cached data in sync with the source of truth. Hard because: aggressive invalidation defeats caching; stale data causes correctness bugs.
70
What is the difference between write-through and write-back caching?
**Write-through**: write to cache and DB simultaneously (consistent, slower writes). **Write-back**: write to cache only, sync to DB later (faster, risk of data loss).
71
What is a CDN and what problem does it solve?
**Content Delivery Network** — caches static assets at geographically distributed edge servers, reducing latency by serving users from a nearby node.
72
What is the purpose of a message queue?
**Decouples producers and consumers**; enables async processing, buffering, retry on failure, and peak shaving. Examples: Kafka, RabbitMQ, SQS.
73
What is the difference between a message queue and a pub/sub system?
Queue: each message consumed by **one consumer**. Pub/Sub: message **broadcast to all subscribers** of a topic.
74
What is eventual consistency?
Replicas may temporarily diverge but will **converge to the same value** given no new updates. Common in AP distributed systems.
75
SQL vs. NoSQL — key trade-offs?
**SQL**: structured schema, ACID, joins, scales vertically. **NoSQL**: flexible schema (document/key-value/graph), scales horizontally, typically eventual consistency.
76
What is database sharding?
Horizontally partitioning data across multiple databases by a **shard key** — each shard holds a subset of rows. Increases write throughput but complicates queries.
77
What is database replication and what are its types?
Copying data across nodes. **Primary-replica** (leader-follower): one writes, others read. **Multi-primary**: multiple write nodes, harder to keep consistent.
78
What are the four ACID properties?
**A**tomicity (all or nothing), **C**onsistency (valid state transitions), **I**solation (transactions don't interfere), **D**urability (committed data persists).
79
What is an index in a database and what is the trade-off?
A data structure (often B-tree) speeding up lookups by field. Trade-off: **faster reads, slower writes** (index must be updated on each write).
80
What is a microservices architecture vs. monolith?
**Monolith**: single deployable unit, simpler to develop/debug. **Microservices**: independent services per domain, independently deployable and scalable — more operational complexity.
81
What is rate limiting and why is it used?
Restricts the number of requests a client can make in a time window — prevents abuse, DoS attacks, and protects downstream services.
82
What is a reverse proxy?
Sits in front of servers, forwards client requests. Provides: load balancing, SSL termination, caching, and hides backend topology. Example: Nginx.
83
What is fault tolerance in distributed systems?
System's ability to continue operating despite failures. Techniques: **replication**, **retries with backoff**, **circuit breakers**, **graceful degradation**.
84
What is a circuit breaker pattern?
After N consecutive failures to a downstream service, the circuit "opens" and immediately returns an error — prevents cascading failures and allows recovery time.
85
What is idempotency and why does it matter in APIs?
An operation is idempotent if calling it **multiple times has the same effect as once**. Critical for safe retries in distributed systems. GET, PUT, DELETE are idempotent; POST is not by default.
86
What is the difference between REST and GraphQL?
**REST**: multiple endpoints, server-defined response shape, good caching. **GraphQL**: single endpoint, client-defined query shape, avoids over/under-fetching.
87
What is a webhook?
Server sends an **HTTP POST to a client URL** when an event occurs — push-based alternative to polling. Client must expose a public endpoint.
Programming
flashcards
Decks in class (12)
# Cards
