Technical analysis of CAP, an open-source, cross-platform screen recording system and its Instant mode screen recording implementation.

CAP breakdown


## Problem statement

You've built a public asset management app that’s become essential for tracking infrastructure and city resources. With early adoption secured, growth is on the horizon—but so are challenges.

As your application scales, demands rise: more users, expanding datasets, and complex regulations. Performance lags, reporting slows, and integrations strain under the load. Inconsistencies may creep in, eroding confidence in your data.

If database evolution isn’t carefully managed, your asset becomes a liability. Is your schema outgrowing its design? Are change histories getting lost? Are integrations breaking as services fall out of sync? Refactoring risks could ripple across your ecosystem.

How will you scale your database without sacrificing stability? What strategies will safeguard your growth while keeping risks in check? We must tackle these key challenges:

- Databases growing beyond initial design assumptions, requiring schema modifications and optimizations.

- Poor repository structuring, making it hard to track changes and ensure consistency.

- Integration issues as different services rely on outdated or conflicting database versions.

- Risks associated with refactoring, especially when making breaking changes that impact multiple services.

Ensuring that databases evolve effectively alongside software applications requires a combination of **knowledge sharing, structured repository management, continuous integration, and controlled refactoring**.

## Evolutionary database design

Evolutionary database design ensures that database changes are made efficiently, without disrupting dependent systems. The key principles include:

- **Knowledge sharing**: Effective collaboration between DBAs and developers.
- **Repository structure**: Storing and versioning database changes systematically.
- **Continuous integration**: Automating verification and preventing schema conflicts.
- **Refactoring**: Managing schema changes and database access modifications.

## Knowledge sharing

DBAs acquire their knowledge through hands-on experience, documentation reviews, and collaboration with developers and system architects. They proactively maintain database understanding across teams by:

- Maintaining a centralized knowledge base to capture schema changes, dependencies, historical decisions, and approved modifications.

- Conducting regular knowledge-sharing sessions to educate developers on database best practices and recent updates.

- Assessing change requests to evaluate their impact on upstream/downstream services and provide guidance to developers.

- Proactively proposing alternative solutions when a requested change poses risks or inefficiencies.

### Example

A developer requests to add a "Last Login" column to the User table. The DBA reviews its impact on authentication services, suggests indexing for performance optimization, and documents the change in the repository while also updating relevant teams.

## Database repository structure

A Database Repository is essential for managing database changes in a structured and controlled manner. It provides a centralized location for tracking modifications, ensuring consistency, and facilitating collaboration between DBAs and developers. A well-maintained repository helps prevent conflicts, enables smooth rollbacks, and supports efficient database evolution.

### Key components

- **Schema definitions & migrations**: Versioned SQL scripts that define database structures and modifications over time.

- **Configuration & credentials**: Environment-specific settings required for database connections and security.

- **Change documentation**: Records of schema updates, rationale, and potential impacts to ensure traceability.

- **Version control system**: A tool (e.g., Git) to track changes, enable rollbacks, and deploy updates across different environments (Development, QA, Production).

### Example

A financial services company experiences inconsistent transaction records after a recent database update. To debug the issue, the team sets up a simulation environment using a snapshot from the Database Repository. By replaying the transaction logs, they identify a schema mismatch between the new and old versions, which caused data to be improperly formatted. The DBA creates a corrective migration script, validates it in the simulation, and then applies it to production, restoring data integrity without further disruption. The DBA also documents the reason for the migration, detailing the schema mismatch, its impact, and the corrective actions taken to prevent similar issues in the future.

## Continuous integration

Every database change follows a structured verification process:

1. Schema changes are tested for compatibility.
2. Data migrations are validated to prevent corruption.
3. Notifications are sent for schema conflicts before deployment.

### Example:

A developer modifies an existing table, but **CI detects a conflict** with another service. The issue is flagged early, allowing necessary adjustments before deployment.

## Database refactoring

Refactoring involves updating schema, migrating data, and modifying database access code. There are two types of changes:

- **Non-breaking changes** (e.g., adding a column) can be implemented without affecting existing services.
- **Breaking changes** (e.g., splitting tables, enforcing non-null constraints) require transitional phases to prevent failures.

### Example:

A company decides to split the "Orders" table into **Customer_Orders** and **Product_Orders**. A transitional phase allows both old and new structures to coexist until all services update their queries.

## Summary

Effective database evolution requires structured communication, versioned changes, and proactive conflict resolution. Utilizing **clear documentation, version control, and automation**, teams can maintain database integrity while adapting to system growth. Visual representations, such as uniform diagrams and migration scripts, help communicate changes effectively. A well-managed database repository serves as a single source of truth for development and operational teams.

## References

- [https://martinfowler.com/articles/evodb.html#DbasCollaborateCloselyWithDevelopers](https://martinfowler.com/articles/evodb.html#DbasCollaborateCloselyWithDevelopers)


As systems scale to meet growing demands, databases must evolve alongside them to maintain performance and integrity. This document explores best practices for managing database changes, maintaining knowledge, and ensuring smooth integration. Topics covered include knowledge sharing, repository structuring, continuous integration, and database refactoring, with real-world examples illustrating their application.

Evolutionary database design: managing change and scaling with the system


![](assets/strategy-design-pattern.pdf)

## Problem statement

The separation of a renowned cookbook, by cuisine culture, into distinct cookbooks(strategies on how to cook dishes): The owner restaurant of the cookbook keeps a single cookbook to prevent the leaking of trade secrets. To maintain standards, the head cooks must use the cookbook to follow the complicated recipes. When the restaurant grows, conflicts happen between head cooks taking turns to use the single cookbook.

=> The cookbook divides into multiple cookbooks based on their type(appetizer, main dish, side dish, ...) and cuisine culture(asian, french, italy, ...). The head cook selects the cook books(strategies) by their station and their dish's cuisine.

## `Strategy` design pattern

Strategy design pattern is about grouping classes with similar functionality, an interface is created to represent their functions, and each class has implementation following the interface.

To choose the correct strategy, the context uses the provided information and selects the appropriate implementation/strategy of the interface.

Example:

```go
// Given an interface to group classes with similar functionality
type Calculation interface {
 func Calculate(x, y int) int // calculate two numbers: x and y, return int result
}

// Implementations
type CalculationAdd Calculation

// Calculate returns the addition result of x and y
func (c CalculationAdd) Calculate(x, y int) int {
 return x + y
}

type CalculationMinus Calculation

// Calculate returns the subtraction result of x and y
func (c CalculationMinus) Calculate(x, y int) int {
 return x - y
}

// The program calculator, from the input operator, calculates two numbers and prints the result
func main() {
 var x, y int
 x, y = env.GetInputNumbers()
 var operation string
 operation = env.GetInputOperation()

 var calculation Calculation
 // Select calculation
 switch operation {
 case "ADD":
 calculation = CalculationAdd
 case "Minus":
 calculation = CalculationMinus
 }

 log.Printf("Result of operation %d %s %d is: %d, x, operation, y, calculation.Calculate(x, y))
}
```

## Use cases

Strategy design patterns commonly used in systems with diverse business flows, a few examples:

- Route planning system that changes based on the provided vehicle type.
- Transaction system that deals with different types of charging, subscription, and discount.

## Vs `State` design pattern

State can be considered as an extension of Strategy. Both patterns are based on composition.
They change the behavior of the context by delegating some work to helper objects.

| Strategy                                                                                                  | State                                                                                                                       |
| --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| An interface is created by the similarity of function, the helper objects select the appropriate strategy | Each class represents a 'State'. The helper objects transition the context to its state and then perform the State behavior |
| Object strategy completely independent and unaware of each other                                          | Doesn't restrict dependencies, may aware and initiate transitions from one state to another                                 |

## Reference

- https://refactoring.guru/design-patterns/strategy


Strategy design pattern, a behavioral design pattern that denote the functionality of a family of interchangeable classes to a interface, the context, with the helper objects, selects the appropriate implementation of the interface.

Strategy design pattern, the concept, use cases and difference with the state design pattern


![](assets/prototype-design-pattern.pdf)

## Problem statement

We want a copy of an object, but the config only initialized at runtime, its fields and methods were private, or its properties were manipulated through multiple processes, so it is difficult to recreate the object. For example:

- DB Access Object with credentials only provide in runtime.
- A ledger object has transaction histories, which are protected through private fields, and exposes a Total() function to get the total balance. To replicate the whole ledger, we must recreate all its transaction histories.

## Prototype design pattern

Request a Clone of the object(Prototype) without the need to look up its class and implementation.

The target object must turn into a 'Prototype' by having a Clone() function to mirror the object with sufficient properties for the user of the cloned object. For example:

```
//The following example is in Go. We are building an RPG with a Hero object, and a new Skill called 'Mimic' needs to create a copy of the Hero with the same level.
type Hero struct {       // level, experience, and killLogIDs are private to avoid editing the Hero object
 level         int64
 experience    int64
 killLogIDs    []int64
}

type (h *Hero) KillConfirm(targetID int64) {
 h.killLogIDs = append(killLogIDs, targetID)
 h.experience += 10

 if h.experience >= 100 {
 h.level += 1
 h.experience -= 100
 }
}

// Creates a clone of the Hero without repeating the whole kill log
type (h *Hero) Clone() Hero {
 return Hero {
 level: h.level,
 experience: h.experience,
 killLogIDs: h.killLogIDs,
 }
}
```

## Case by case

When developing a system, the Prototype design pattern works in tandem with other creation patterns:

- Factories, abstract factories, and builders help create the original object. Prototype provides a clone of the object without the need to call the above patterns
- Prototype behaves opposite to the singleton pattern. Singleton pattern focuses on having a single instance for operational flow. Prototype can Clone the object in the middle of its processing flow for other uses without changing the original object.

The most common use cases for Prototype design patterns are:

- Credential/Access objects for Database or external services
- Ledger/Bank statement objects, we clone the object to the statistics and simulations.

## Reference

- https://refactoring.guru/design-patterns/prototype


Prototype, one of the creational patterns, minimize efforts when recreating new from the exist object by cloning the 'prototype' of it.

Going through use cases of the prototype design pattern and it place among the creational patterns


![](assets/c4-modelling.pdf)

## Problem statement

When conveying the software architecture to non-tech people/other developers, we will face the following restrictions:

- UML complexity or nondescriptive box and line drawing.
- Lacking domain knowledge or context.
- Confusing Technical terms and vocabulary.
- Difficulties when doing direct communication, and nonconclusive presentation of the solution.

## C4 model

The C4 model leverages abstractions as common languages and visualization to describe the structure of the software system.

## Abstractions

Abstractions are a means for developers and non-tech/business people to understand the context and the software architecture that is outside of their knowledge domain/level of expertise.

Abstractions must be devised and agreed upon by all involved parties. The process will consume a substantial amount of effort and time when going through multiple meetings and selecting the people responsible as the source of truth for the abstractions.

To help define the abstractions, the C4 model uses the granularity in software architecture and divides the level of abstractions into:

- **Context** of the Software system.
- **Container**.
- **Component**.
- **Code**.

### System-level context

System-level context is the highest level of abstraction. It is a package, a composition of the software system and other dependent systems, that delivers value to its users.

The system context abstractions include:

- The user of the system(people or machine), the context that the user was placed in, and the pain points.
- The main software system, the provided solution, and how it solves pain points.
- Dependent systems, why those are needed, and which information is required from the main software system.

### Container

Multiple containers exist inside a system context, each container is an abstraction of an application or a datastore. A container is something that needs to be running for the overall software system to work.

Example: A shopping e-commerce system requires a web/mobile application to display the inventory, a back-end API to calculate and return the available inventory, and a data store to store all the inventory information. The web/mobile application, back-end API, and data store are the containers, each container is responsible for the operation of the e-commerce system.

### Component

Component is a set of functions and classes bounded behind an interface. Each component helps complete the operational flows of its parent container.

Example: When sending a request to withdraw to the back-end API container of a banking system:

- The OAuth component authenticates the user requesting the withdrawal.
- Ledger component checks the available withdrawal amount.
- The notification/email component sends the withdrawal status to registered contacts.

### Code

Code is the specific implementation that built the component. Through code elements, the component describes in detail its conditions, outputs, exceptions, optional and fallback flows.

Example: An Authentication component selects the appropriate method based on the user credentials:

- If is a pair of email and password, validates the email pattern, verifies the password and the hashed password stored in the database.
- If is a token, verifies the hash is from the same user, and checks if the token is expired.

## Visualization

To visualize the software architect abstractions, we can use UML elements, box and line diagrams, etc... and enforce these guidelines:

- The diagram must convey the solution meant for that specific domain.

- The diagram elements must be clear, uniform, and meaningful and have a legend to explain the usage of each element.

- Strive to lose the <https://c4model.com/bingo/>.

## Case by case

The C4 model’s diagram, for the amount of effort and the value that it brings, will most likely be the source of truth for other design documents, diagrams, and feature discussions, and as a result, the level of abstractions and how we visualize it should focus on the value we want to deliver.

## Reference

- <https://c4model.com/>


Understanding and conveying software architecture can be a daunting task, especially when dealing with non-technical stakeholders or diverse development teams. This article delves into the challenges of traditional methods like complex UML diagrams and non-descriptive box-and-line drawings. We introduce the C4 model, a powerful framework that simplifies these challenges by using layered abstractions and visualizations. Explore how the model breaks down software architecture into comprehensible levels, Context, Container, Component, and Code, and offers guidelines on creating effective diagrams. Real-world examples illustrate the application of the C4 model, making it an invaluable tool for creating a shared understanding and ensuring clear, meaningful communication among all parties involved.