Back to Sports Hub portal product map
This Architecture Vision elicits the significant architecture drivers such as business, functional, nonfunctional requirements and constraints, defines architecture, and develops a roadmap for Single Entry implementation. The document is intended as a primary technical guidance into solution implementation for the development team.
The document describes the proposed Single Entry architecture towards development of the solution that will satisfy business, functional, non-functional requirements and constraints provided by the Client. This Architecture Vision covers the following information: • Significant architectural drivers for the Solution • Proposed software architecture of the solution based on these drivers • Technology stack and environment definitions • Operations specific perspectives • Development road map and high level estimates for effort, team size and skill sets.
The section Executive Summary highlights key architectural decisions made for the solution described in 3.1 Business Case. These decisions are defined and discussed in depth in 4 Solution Architecture while Implementation Roadmap lays out the proposed milestones, estimates, and team to implement the provided architecture vision. This section also summarizes the key business and technical risks related to the solution implementation. These risks are uncovered in depth in the rest of the document.
The section outlines key design decisions about the solution including the architecture big picture and most essential technologies and external services to rely on. The solution will be implemented as a cloud based web service and deployed to the Cloud Platform Provider (GCP, Azure, AWS) using it’s managed services capabilities. The structured data will be stored in the scalable cloud RDBMS storage provided by the Cloud Platform Provider with multy-AZ replication to ensure data availability and backup as required by the solution’s SLA. The solution will be integrated as a REST-ful client with the third-party service New Aggregator to get news and store it the local datastorages.
The section lists the key risks related to the solution design and implementation. It also lists key open issues where architectural decisions have not been made yet or are likely to change.
| Risk description | Mitigation strategy |
|---|---|
| There is a risk of failure of news aggregator, but it should now affect end users on our portal | Store all the data within platform instead of linking to original sources |
The section captures significant requirements driving the solution architecture and road map. The requirements which are not influencing the solution architecture are typically excluded from this section and can be found in the product backlogs.
The section lays out the business case for the solution Sports Hub Portal.
Figure 1. Business level view of Sports Hub Portal
The solution will enable the users to review all news using web/mobile devices, manage news preferencese, subsribe to interested topics & receive the newsletters on regular bases. The solution will be deployed on the GPC/AWS/Azure cloud as web application.
The section enumerates essential business goals for the solution
| # | Description |
|---|---|
| BG-1 | Create sports news platform to provide more flexibility to users: newsletters subsriptions, news personalizations, news review using web/mobile devices |
The section enumerates solution major features.
| # | Description |
|---|---|
| F-1 | Endusers can read news related to different kinds of sports |
| F-2 | Endusers can subscribe to the sports news of their choice |
| F-3 | Endusers can receive the newsletters via email |
| F-4 | Endusers can manage the kind of news they want to see (e.g. news related to the specific kind of sports,league or team) |
| F-5 | Admins can define/modify the structure and content of the portal |
The section lists the constraints accounted for in the designed solution.
| # | Description |
|---|---|
| CON-1 | A minimum of 1000 simultanious users must be supported |
| CON-2 | Solution should be cloud agnostic as much as possible to simplify migration to another cloud provider |
| CON-3 | The application must work in all modern browsers |
| CON-4 | The application should be built following the REST principles |
| CON-5 | The application should use Cloud service for storing images and video files instead of previewing this data from original news aggregator |
A Quality Attribute Scenario is an unambiguous and testable requirement for one or more Solution Quality Attributes such as Performance, Usability, Maintainability and others. This section lists and prioritizes the scenarios pertinent to the designed solution.
| # | QA | Scenario | Priority |
|---|---|---|---|
| QA-1 | Security | Credentials always entered by the user during log-in are transferred to the server over encrypted, secure channel without the chance of sniffing by third party. | H |
| QA-2 | Performance | UI max response time (includes API endpoints max response time) < 10 sec | M |
| QA-3 | Performance | UI average response time (Includes API endpoints average response time) < 3 sec | M |
| QA-4 | Performance | Application first Page upload time < 2 SEC | M |
| QA-5 | Scalability | Application should support at least 100 simultaneous users at same time | M |
| QA-6 | Compatibility | Solution co-exists and interoperates with the existing news providers. | H |
| QA-7 | Security | Audit events & logs: should always provide info about what has happened, who did it and when & retention policy for that data should be 365days | M |
| QA-8 | Availability | Solution should be available 95% of total hours | H |
The section Solution Architecture is primary for the Architecture Vision document. It defines and reasons about the solution architecture design based on the architecturally significant requirements and constraints identified in the section 3 Architectural Drivers.
The section includes a list of architectural views covering the designed solution along with the context it runs in on the high level. The view defines the primary solution components collaborating with the external systems and services. It is driven by the 3.1 Business Case.
Figure 2. Solution Context
Table of annotated elements:
| Name | Description |
|---|---|
| Sports News Solution | Responsible for implementation of all business logic |
| Identity Provider | Responsible for authentication functionality |
| Cloud Provider | Responsible for hosting of deployed solution |
| Email Provider | Responsible for newsletters mailing |
| Push Notifications | Responsible for push notification functionality |
| News Aggregator | Responsible for providing content to portal |
The view defines the runtime decomposition of the server-side part of the solution. It is driven by the 3.1 Business Case and the architecture best practices applicable to the cloud-based applications. The view context is defined by the view 4.1.1 Solution Context where this section represents decomposition of Cloud Based Solution component.
Figure 3. Basic Cloud Solution Decomposition
The solution is decomposed into several parts documented below combining several standard architectural patterns.
| # | Description |
|---|---|
| Portal UI | Responsible for Web UI representation of solution |
| Desktop App | Responsible for desktop representation of solution for admins |
| Mobile App | Hybrid application, responsible for Mobile representation of solution |
| Static Files | Responsible for storage of unstructured data e.g. images, video etc |
| Portal API | Responsible for business logic related to communication with frontend and database |
| Operational DB | Responsible for storage of all structured info: users & their details, news, configurations info etc |
| RawData | Responsible for storage of all nonprocessed data |
| PushNotification Sender | Responsible for push notification functionality |
| Mail Sender | Responsible for send emails logic |
| Identity Provider | Responsible for authenticatino of users using social networks |
| News Aggregator | Responsible for news provisionining |
| News Processor | Responsible for moving ready news to Operational DB |
The view defines the runtime decomposition of the server-side part of the solution. It is driven by the 3.1 Business Case and the architecture best practices applicable to the cloud-based applications. The view context is defined by the view 4.1.1 Solution Context where this section represents decomposition of Cloud Based Solution component.
Figure 4. Medium Cloud Solution Decomposition
The cloud based part of the solution is decomposed into several parts documented below combining several standard architectural patterns.
| # | Description |
|---|---|
| Portal UI | Responsible for Web UI representation of solution |
| Mobile App | Hybrid application, responsible for Mobile representation of solution |
| Desktop App | Responsible for desktop representation of solution for admins |
| Static Files | Responsible for storage of unstructured data e.g. images, video etc |
| Portal API | Responsible for business logic related to communication with frontend and database |
| Notification Service | Responsible for encapsulation of logic related to push notifications. Service might have a few different implementation which depends on each push notification provider |
| Mail Service | Responsible for encapsulation of logic related to emails. Service might have a few different implementation which depends on each mail provider |
| Auth Service | Responsible for encapsulation of logic related to users authentication |
| Operational DB | Responsible for storage of all structured info: users & their details, news, configurations info etc |
| RawData | Responsible for storage of all nonprocessed data |
| Cache DB | Responsible for caching logic for data which are accessed frequently |
| Search Engine | Responsible for optimization and preparation of data in format which is suitable for search and indexes related tasks |
| PushNotification Sender | Responsible for push notification functionality |
| Mail Sender | Responsible for send emails logic |
| Identity Provider | Responsible for authenticatino of users using social networks |
| News Aggregator | Responsible for news provisionining |
| News Processor | Responsible for moving ready news to Operational DB |
The view defines the runtime decomposition of the server-side part of the solution. It is driven by the 3.1 Business Case and the architecture best practices applicable to the cloud-based applications. The view context is defined by the view 4.1.1 Solution Context where this section represents decomposition of Cloud Based Solution component
Figure 5. Hard Cloud Solution Decomposition
The cloud based part of the solution is decomposed into several parts documented below combining several standard architectural patterns.
| # | Description |
|---|---|
| Portal UI | Responsible for Web UI representation of solution |
| Mobile App | Hybrid application, responsible for Mobile representation of solution |
| Desktop App | Responsible for desktop representation of solution for admins |
| Static Files | Responsible for storage of unstructured data e.g. images, video etc |
| CDN | Responsible for edge caching of UI assets to improve performance |
| API Management | Responsible for API management and versionining within solution |
| Portal API | Responsible for business logic related to communication with frontend and database |
| Sockets | Responsible for two way communication with end users devices |
| Queue | Responsible for communication between news injector and sockets |
| Notification Service | Responsible for encapsulation of logic related to push notifications. Service might have a few different implementation which depends on each push notification provider |
| Mail Service | Responsible for encapsulation of logic related to emails. Service might have a few different implementation which depends on each mail provider |
| Auth Service | Responsible for encapsulation of logic related to users authentication |
| Operational DB | Responsible for storage of all structured info: users & their details, news, configurations info etc |
| RawData | Responsible for storage of all nonprocessed data |
| Cache DB | Responsible for caching logic for data which are accessed frequently |
| Search Engine | Responsible for optimization and preparation of data in format which is suitable for search and indexes related tasks |
| PushNotification Sender | Responsible for push notification functionality |
| Mail Sender | Responsible for send emails logic |
| Identity Provider | Responsible for authenticatino of users using social networks |
| News Aggregator | Responsible for news provisionining |
| News Processor | Responsible for moving ready news to Operational DB |
Technology stack may vary on your choice:
| Name | Version | Description |
|---|---|---|
| Framework1 | x.x | Responsible for a, b, c |
| Library2 | 3.0-RC1 | Responsible for a, b, c |
| Library3 | x.x.x.x | Responsible for a, b, c |
Infrastructure GCP: GCP is used as main and single cloud provider. Services that is used by solution are App Engine, Cloud Storage, Cloud Functions, Cloud SQL for MySQL, Memorystore, Cloud BigQuery, Stackdrive, Cloud Pub/Sub, Cloud Scheduler, Cloud CDN.
Figure 6. Dedployment Diagram GCP
Infrastructure Azure: Azure is used as main and single cloud provider. Services that is used by solution are WebApps, Azure CDN, Azure Storage, Azure Functions, Azure SQL, Azure Cognitive Search, Azure Redis, Azure Scheduler. Azure Service Bus.
Figure 7. Dedployment Diagram Azure
Infrastructure AWS: AWS is used as main and single cloud provider. Services that is used by solution are Elastic Beanstalk, AWS Lambdas, AWS S3, Elasticsearch, Amazon SQS, AWS Batch Scheduler, AWS ElastiCache, Amazon RDS, Amazon CloudFront, AWS API Gateway.
Figure 8. Dedployment Diagram AWS
Environments: For transitional phase there will be four environments: development, testing, staging and production. Development environment use minimal cloud resources but similar architecture. Testing environment use intermediate resource allocation for full QA testing. Staging environment is a copy of production environment and is used for load, performance and user acceptance testing. Production environment is scalable and fault tolerant.