uis-cloud-computing/design.md

Design Document

Keep this document brief (2–4 pages), clear, and up-to-date throughout the project. You may use Mermaid diagrams for architecture visuals.

Field	Value (fill in)
Project Name	Personal Finance Tracker
Team Members	Lukáš Trkan, Dejan Ribarovski
Repository URL	https://github.com/dat515-2025/Group-8
Version	v0.1 (update as you iterate)
Last Updated	YYYY-MM-DD

How to use this template

• Replace all placeholders with your project-specific content.
• Keep explanations concise; link to code or docs when helpful.
• Update this document as the design evolves to match the final implementation.

---

1. Overview

Briefly describe the application and its purpose.

• Problem statement: What problem are you solving?
  • Keeping track of all personal finances across multiple bank accounts, cash is not easy. We want to simplify it.
• Target users / personas: Who benefits from this?
  • We aim to help people to keep better track of their finance flows, so people can plan bigger expenses or find ways to save money.
• Primary objectives: 3–5 bullet points.
  • Pass th
• Non-goals: What is explicitly out of scope?
• Key features: Short bullet list of core functionality.

2. Architecture

High-level architecture, main components, interactions, and data flow. Include a system diagram.

2.1 System diagram

flowchart LR
  client[Client/UI] --> api[API Gateway / Web Server]
  api --> svc1[Service A]
  api --> svc2[Service B]
  svc1 --> db[(Database)]
  svc2 --> cache[(Cache)]
  svc2 --> ext[(External API)]

• Components and responsibilities: What does each box do?
• Data flow: How does data move between components?
• State management: Where is state stored (DB, cache, object store)?
• External dependencies: APIs, third-party services, webhooks.

2.2 Data model (if applicable)

• Core entities and relationships (ER sketch or brief description).
• Example records or schemas (link to files or include concise snippets).

2.3 APIs (REST/gRPC/GraphQL)

• Interface style and rationale.
• Link to OpenAPI/Proto files, or list a few key endpoints/RPCs.

3. Technologies

List the cloud services, libraries, and tools you will use and why.

Technology / Service	Role / Where Used	Why chosen (brief)	Alternatives considered

Notes:

• Languages & frameworks (e.g., Go, Node, Python; Gin, Fiber, Echo).
• Cloud provider and managed services (compute, DB, storage, messaging).
• CI/CD, IaC, containerization.

4. Deployment

Describe the deployment strategy and infrastructure requirements.

• Environments: dev / staging / prod (if applicable).
• Runtime platform: Docker, Compose, Kubernetes, serverless, PaaS.
• Infrastructure diagram (optional):

flowchart TB
  subgraph Cloud
    lb[Load Balancer]
    asg[Service / Deployment]
    db[(Managed DB)]
    bucket[(Object Storage)]
  end
  user((User)) --> lb --> asg --> db
  asg --> bucket

• Configuration & secrets: Env vars, secret manager, .env files (never commit secrets).
• Build & release: How artifacts are built; link to CI/CD if used.
• Deployment steps: Summarize here; full, reproducible steps must be in report.md.
• Scaling strategy: Horizontal/vertical scaling, autoscaling triggers.

---

Optional Sections

Include the sections below as applicable to your project.

Security

• Authn/Authz model; data protection; TLS/HTTPS; secrets handling; dependency scanning.

Scalability

• Expected load; performance targets; bottlenecks; caching; rate limits.

Monitoring & Logging

• Health checks; logs; metrics (e.g., Prometheus); dashboards; alerting.

Disaster Recovery

• Backups; restore procedures; RPO/RTO targets; failure scenarios.

Cost Analysis

• Main cost drivers; pricing model; cost-saving measures; budget estimate.

References

• Links to papers, docs, blog posts, prior art, and any external resources.

---

Change Log

• v0.1 – Initial draft
• v0.2 – Architecture updated to match implementation
• v1.0 – Final version reflecting delivered system