Middleware Architecture Proposal Flashcards

0.0(0)
Studied by 0 people
call kaiCall Kai
Locked
learnLearn
examPractice Test
spaced repetitionSpaced Repetition
heart puzzleMatch
flashcardsFlashcards
GameKnowt Play
Card Sorting

1/20

flashcard set

Earn XP

Description and Tags

Vocabulary flashcards covering requirements, definitions, verification approaches, delivery plan activities, sync meeting schedules, and deliverables from the Middleware Architecture Proposal Project Briefing.

Last updated 8:05 PM on 9/10/26
Name
Mastery
Learn
Test
Matching
Spaced
Call with Kai
Chat

No analytics yet

Send a link to your students to track their progress

21 Terms

1
New cards

Chrisitan Bertsch / We are 4U GmbH

The author/organization issuing the project briefing for the middleware architecture proposal.

2
New cards

Project Duration & Budget Allocation

A 6-week initiative with 34 hours/week part-time allocation, totaling a budget of 204 hours.

3
New cards

Zero-Downtime Deployment Requirement

Operational definition requiring support for Blue/Green, Canary, or Rolling Update strategies during continuous 7/24 operations, verified by measuring deployment time vs. service interruption duration.

4
New cards

Monitoring & Observability Requirement

Operational definition requiring metrics, structured logging, distributed tracing, and defined alerting thresholds, verified by accessible dashboards and alerts triggered on simulated failures.

5
New cards

Performance Requirement

Operational definition requiring target latency (e.g., <200ms p95) and throughput (requests/sec), verified by load testing results documenting compliance with targets.

6
New cards

Error Handling Requirement

Operational definition requiring retry policies, circuit breakers, and dead-letter queues, verified by simulated failure scenarios showing recovery behavior.

7
New cards

API Definitions Requirement

Operational definition requiring an API-first approach using OpenAPI/Swagger or gRPC with a documented versioning strategy, verified by Swagger/OpenAPI spec files in the repository.

8
New cards

Microservices Design Requirement

Operational definition requiring defined service decomposition boundaries and specified inter-service communication protocols, verified by component diagrams showing service boundaries and dependencies.

9
New cards

Caching Strategy Requirement

Operational definition requiring a defined cache layer architecture (distributed cache, invalidation strategy), verified by cache hit-rate metrics and invalidation flow documentation.

10
New cards

Redundancy & HA Requirement

Operational definition requiring high availability architecture with defined failover behavior, verified by a disaster recovery runbook demonstrating failover procedure.

11
New cards

Flexible Deployment Requirement

Operational definition requiring containerized deployments with orchestration capability (Kubernetes-compatible), verified by Dockerfiles and deployment manifests in the repository.

12
New cards

Version Control Requirement

Operational definition requiring all source code to be managed in Bitbucket with CI/CD pipeline integration, verified by pipeline execution logs and merge request workflow documentation.

13
New cards

MoSCoW Method

A prioritization technique used in Week 2 to categorize requirements into Must, Should, Could, and Won't.

14
New cards

Sync Meeting #1

A 30-minute Week 1 sync meeting focused on confirming shared understanding of requirements and verifying testable acceptance criteria.

15
New cards

Sync Meeting #2

A 30-minute Week 2 sync meeting focused on reviewing and approving the requirements specification document and business value priorities.

16
New cards

Sync Meeting #3

A 30-minute Week 3 sync meeting focused on validating technology patterns and shortlisting promising tools and patterns.

17
New cards

Sync Meeting #4

A 30-minute Week 4 sync meeting focused on reviewing draft proposal options A, B, and C to evaluate trade-offs and clear distinctions.

18
New cards

Sync Meeting #5

A 30-minute Week 5 sync meeting focused on assessing feasibility, scaling strategies, and risk review of remaining architecture options.

19
New cards

Sync Meeting #6

A 45-minute Week 6 final sync meeting focused on full presentation of three proposals, recommendations, and decision-ready materials.

20
New cards

Escalation Path

The requirement to immediately escalate any technical or project blocker lasting greater than 24 hours rather than waiting for the Friday sync.

21
New cards

Deliverables Checklist

The final package due by Week 6 containing the Requirements Specification Document, 3 Architecture Proposal Documents (max. 10 pages each), Comparison Matrix, Technology Stack Recommendation, Risk Register (top 5 risks per option), and 1-page Executive Summary.