Name: Client Cache Garbage Collection Proposal
Organization: PWV Consultants
||Hours||Rate / Hr.||Period|
After the month-end, you’ll finalize your logs and then create a Snapshot proposal, referencing this page. And then here, you can reference the link to your Snapshot proposal.
Polywrap currently implements a client cache for each wrapper that is used for the entire lifetime of the client instance. This can cause scaling issues in the future as the cache can become bloated when many wrappers are queries and downloaded into the cache. To correct this there will need to create a system that allows some form of rules related to when the application should remove certain wrappers from the cache.
Architecture Plan will be delivered along with estimates and paths for execution and development of the following features:
- Review and comparing existing implementations of garbage collection such as Apollos gb/cache eviction, Rust (no real GC, optimized) etc.
- Implementation details and components related to garbage collection.
- Suggested implementation for rules related to how to allow developers to specify the behavior of the garbage collector.
- Implementation details related to how to cycle through without erroring out if limit is hit.
- Pros and cons of specific implementation details related to security/efficiency and developer friendliness.
An architecture plan will lay the roadmap for further execution and development that includes the following elements:
This section will outline Background Context, Scope, and Requirements.
This section breaks down each component of the architecture of the project describing what and how and why.
This lays out the physical and cloud infrastructure components and how they relate to each other.
This lays out the individual components. For instance a Data Decryption component - where it lives within the system.
Outlines how do the components communicate with each other.
Lays out the literal steps in the processes from component to component via a real-world scenario(s).
This outlines the state the data is in.
This will show the timing of how data flows around and through what protocols.
Shows inventory of all things being used, and what other alternate plans/methods were considered
Why we choose this path usually related to pen and paper testing or scenario breakdowns.
Third parties or vendors we source from (cloud/DC/physical).
How this will get out into the real world as a POC.
Estimate of hours for each component of the technical plan.
Supplemental Document (usually a spreadsheet) as needed.
How deliverable of the real world POC will be delivered.
Any outstanding questions or known unknowns. Additional information and or sections are often added depending on the project needs as they develop. Plans are typically 30-150 pages depending on what is sufficient to document what needs to be understood to build the project. The plan is typically presented as a PDF that we review in at least one meeting and then discuss in further meetings and revise for specificity. We have and can on request also modify the plan into a brief slide deck that isolates most of the diagrams, lists, and schedules.