Skip to main content

General Overview

Purpose
This document describes Aventian’s database architecture, naming conventions, schema layout, RBAC primitives, operational practices, and integration guidance for adding new products under the Aventian umbrella. It is intended for backend engineers, SREs, and integrators.

1. High-level Architecture​

  • Aventian (Umbrella App)
    • Responsible for organization/team management, user onboarding and authentication, RBAC (roles & privileges), profile management, billing/subscriptions, and platform-level master data.
    • Stores its core data in a centralized Aventian database instance.

2. Aventian Core DB (avn-<environment>)​

  • Instance name convention: avn-<environment> (e.g., avn-prod, avn-staging).
  • Schemas of interest:
  • aventian — primary application tables (users, teams, products, role mappings, connection strings, secrets pointer).
  • aventian_audit — audit history and activity logs.
  • Version: Document and tag DB schema version in migrations.
  • Data retention: Default retention policy (audit, logs, short-term state) — e.g., 8 days (adjust per compliance).

4. Aventian services used by the product (DB-focused)​

When a product integrates under Aventian it leverages these database & platform services:

  • Product registration & metadata in tbl_master_products (provisioning script paths, dashboard URL, allowed resource types).
  • DB provisioning: Aventian stores encrypted connection strings in tbl_teams / team_db_connections and tbl_team_product_assoc for each team subscription.
  • RBAC data store (centralized): roles, privileges, resources, templates and mappings are stored in the Aventian core DB tables (see below).
  • Role/Privilege lookups: product calls GetUserDetails or management APIs which query these tables and return roles/privileges (including invisible system roles).
  • Audit & Activity tables: product-level operations can be logged to product DB audit tables or Aventian core aventian_audit.
  • Redis cache (DB metadata cache): connection strings and role lookups may be cached using keys like team:dbconn:<team_id> or user:roles:<user_id>.

Integration engineers should assume authoritative RBAC data lives in Aventian core DB and product must call that API for runtime authorization.

4. Security & Secrets Management​

  • Secret storage:
    • GCP Secret managers are used to store the Aventian's DB credentials.
  • Encryption:
    • All DB credentials with respect to teams are stored in Aventian core are encrypted using 2-way encryption mechanism.

5. Auditing & Activity Logging​

  • Audit tables (e.g., in aventian_audit) capture user and system actions: role changes, team creation, product subscription events, user creation events.

  • Login / activity table: store user_email, team_id, product_id, action, timestamp, ip entries for invitation acceptance and team switching workflows.

6. Operations, Monitoring & Backups​

  • Monitoring: Track DB CPU, memory, connection counts, and query latency. Alert on abnormal growth or backup failures through GCP montoring system

  • Backups: CloudSQL use automated scheduled backups on daily basis. Backups are stored in the multiple zones.

  • Retention: A backup is by default retained for 8 days.

  • Scaling: If an instance goes over CPU threshold, consider manual vertical scaling.

  • Restore: In case of zone failure, the database will be restored manually by the IT team.

7. Disaster Recovery Plan (DRP)​

The DR plan is designed to restore service in the event of a significant outage affecting the primary us-central1 region.

  • Recovery Point Objective (RPO): The maximum acceptable data loss is 24 hours, consistent with the daily backup schedule.

  • Recovery Time Objective (RTO): The target time to restore the Cloud SQL databases from backups is a maximum of 3 hours.