-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Anton
committed
Nov 5, 2024
1 parent
4e1c4e1
commit 9712697
Showing
5 changed files
with
210 additions
and
75 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,9 +1,22 @@ | ||
| [[section-architecture-constraints]] | ||
| == Architecture Constraints | ||
| - Con1: The platform must comply with data protection laws (e.g., GDPR, CCPA) and intellectual property regulations. This includes implementing necessary data privacy measures, consent mechanisms, and content moderation practices to avoid legal liabilities. | ||
| - Con2: The solution must adhere to budgetary constraints for development, deployment, and ongoing operational costs. | ||
| - Con3: .NET technologies | ||
| - Con4: Use Google Authentication, | ||
| - Con5: Use Azure Cloud | ||
| [cols="2*", options="header"] | ||
| |=== | ||
| | ID | Quality Category | ||
|
|
||
| | Con1 | ||
| | The platform must comply with data protection laws (e.g., GDPR, CCPA) and intellectual property regulations. This includes implementing necessary data privacy measures, consent mechanisms, and content moderation practices to avoid legal liabilities. | ||
|
|
||
| | Con2 | ||
| | The solution must adhere to budgetary constraints for development, deployment, and ongoing operational costs. | ||
|
|
||
| | Con3 | ||
| | .NET technologies | ||
|
|
||
| | Con4 | ||
| | .NET Use Google Authentication, | ||
|
|
||
| | Con5 | ||
| | Use Azure Cloud | ||
|
|
||
| |=== |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,69 @@ | ||
| [[section-technical-risks]] | ||
| == Risks and Technical Debts | ||
| == Risks | ||
| [cols="1,3,4", options="header"] | ||
| |=== | ||
| | Risk ID | Risk Description | Mitigation Strategy | ||
|
|
||
| | R1 | ||
| | High load from influencers causing performance degradation due to large-scale timeline updates. | ||
| | Implement a separate materialized view for influencer posts to reduce load on the main timeline. Use caching and batch processing. | ||
|
|
||
| | R2 | ||
| | Dependency on external APIs, leading to potential service disruptions if APIs are down. | ||
| | Use local caching and circuit breakers to handle temporary outages and minimize the impact on users. | ||
|
|
||
| | R3 | ||
| | Cost overruns due to high storage and compute needs as the system scales. | ||
| | Optimize storage through data compression, archiving, and implement auto-scaling to manage resources dynamically. | ||
|
|
||
| | R4 | ||
| | Inconsistent data updates due to eventual consistency in microservices. | ||
| | Use idempotent operations and reconcile data periodically to ensure consistency across services. | ||
|
|
||
| | R5 | ||
| | Risk of unauthorized access and data breaches. | ||
| | Enforce strong access controls, data encryption, and multi-factor authentication for enhanced security. | ||
|
|
||
| | R6 | ||
| | Outdated data in influencer timelines due to cache staleness. | ||
| | Set appropriate cache expiration times and implement cache invalidation strategies to keep data fresh. | ||
| |=== | ||
|
|
||
| == Technical Debts | ||
|
|
||
| [cols="1,3,4", options="header"] | ||
| |=== | ||
| | Debt ID | Technical Debt Description | Impact and Remediation Strategy | ||
|
|
||
| | TD1 | ||
| | Lack of centralized logging system for monitoring and troubleshooting. | ||
| | Makes debugging across services difficult. Remediate by implementing a centralized logging solution such as Azure Application Insights or ELK Stack. | ||
|
|
||
| | TD2 | ||
| | Incomplete API versioning, leading to backward compatibility issues. | ||
| | Causes disruptions for clients using older API versions. Remediate by adopting consistent API versioning and supporting multiple versions. | ||
|
|
||
| | TD3 | ||
| | Insufficient automated tests for microservices. | ||
| | Leads to increased risk of errors during deployment. Remediate by developing automated test suites covering unit, integration, and end-to-end tests. | ||
|
|
||
| | TD4 | ||
| | Hard-coded configurations across services. | ||
| | Reduces flexibility in deployment and configuration management. Remediate by using a centralized configuration management tool, like Azure App Configuration. | ||
|
|
||
| | TD5 | ||
| | Inconsistent error handling and retry mechanisms in services. | ||
| | Leads to unpredictable behavior during failures. Remediate by standardizing error handling and retry policies across services. | ||
|
|
||
| | TD6 | ||
| | Limited resilience testing for failure scenarios (e.g., network partitions). | ||
| | Increases the risk of unexpected downtime. Remediate by conducting regular chaos engineering exercises to test service resilience. | ||
|
|
||
| | TD7 | ||
| | No clear deprecation policy for obsolete services or APIs. | ||
| | Results in bloated codebase and confusion among developers. Remediate by establishing a deprecation policy with clear timelines for phasing out outdated services or versions. | ||
| |=== | ||
|
|
||
|
|
||
|
|
||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,15 +1,59 @@ | ||
| [[section-glossary]] | ||
| == Glossary | ||
|
|
||
| [cols="1,3", options="header"] | ||
| |=== | ||
| | Term | Definition | ||
|
|
||
| | API Gateway | ||
| | A server that acts as an entry point for clients, managing requests to multiple backend services in a microservices architecture. | ||
|
|
||
| [cols="e,2e" options="header"] | ||
| |=== | ||
| |Term |Definition | ||
| | Active-Active Strategy | ||
| | A high availability approach where multiple regions or instances are active simultaneously, ensuring seamless failover and load balancing. | ||
|
|
||
| |<Term-1> | ||
| |<definition-1> | ||
| | Microservices | ||
| | An architectural style that structures an application as a collection of loosely coupled services, each responsible for a specific business capability. | ||
|
|
||
| |<Term-2> | ||
| |<definition-2> | ||
| |=== | ||
| | API Versioning | ||
| | The practice of managing different versions of an API to maintain compatibility and support for clients using older versions. | ||
|
|
||
| | Eventual Consistency | ||
| | A consistency model in distributed systems where updates are not immediately reflected across all nodes but will eventually converge to the same state. | ||
|
|
||
| | High Availability | ||
| | A system design approach that ensures minimal downtime and continuous operation, often achieved through redundancy and failover mechanisms. | ||
|
|
||
| | CI/CD Pipeline | ||
| | A set of automated processes for continuous integration and continuous deployment, enabling rapid and reliable software delivery. | ||
|
|
||
| | Cache | ||
| | A temporary data storage layer that stores frequently accessed data to reduce retrieval times and improve performance. | ||
|
|
||
| | Chaos Engineering | ||
| | The practice of testing a system's resilience by intentionally introducing failures to observe how it responds and identify areas for improvement. | ||
|
|
||
| | Centralized Logging | ||
| | A logging approach where logs from various services are collected and stored in a central location for monitoring and troubleshooting. | ||
|
|
||
| | CRUD Operations | ||
| | Basic data operations: Create, Read, Update, and Delete, commonly used in database management. | ||
|
|
||
| | Fault Tolerance | ||
| | The ability of a system to continue operating properly in the event of a failure of some of its components. | ||
|
|
||
| | Load Balancer | ||
| | A component that distributes incoming network traffic across multiple servers to ensure availability and reliability. | ||
|
|
||
| | Namespace | ||
| | A logical grouping used to organize resources, often used in Kubernetes to isolate applications or environments. | ||
|
|
||
| | Scalability | ||
| | The capability of a system to handle increased load by adding resources, such as compute power or storage. | ||
|
|
||
| | Service Bus | ||
| | A messaging infrastructure that allows applications to communicate with each other in a decoupled way, commonly used in distributed systems. | ||
|
|
||
| | SLA (Service Level Agreement) | ||
| | A commitment between a service provider and a client that defines the expected level of service performance, availability, and support. | ||
|
|
||
| |=== |