Prepared for Hassan Allam
Your data environment, in accounts you own. This proposal sets out what you provide, where information is stored, and how Sakneen will operate the application.
Explore the requirementsThis is the intended setup, subject to implementation, migration and joint acceptance before production activation. Final scope, service levels and responsibilities will be recorded in the operating agreement.
THE STARTING POINT
Hassan Allam provides the accounts and access. Sakneen then configures the database and the agreed cloud resources. Regions, sizing and permissions are confirmed together before provisioning.
Sakneen will configure the application database, users, collections and indexes within the access you approve. Choose either of the hosting options below; the shared requirements apply to both.
| Item | Proposed requirement |
|---|---|
| Database only | MongoDB holds application records, file references and operational state. Offer PDFs, attachments and other file contents remain in Google Cloud Storage with either hosting option; they are not stored on the MongoDB servers. |
| Version | MongoDB 8.x as the proposed baseline; final version confirmed during compatibility validation. |
| Topology | A production replica set with at least three data-bearing nodes, supporting transactions and change streams. This applies to either hosting option. |
| Access | Named setup access and a separate, least-privilege application identity. Sakneen will provide the access schedule. |
Start at M20 for a validated low-traffic workload and grow with measured demand. MongoDB recommends M30 or higher for production generally; M20 is a lower-cost starting choice, not a capacity guarantee. Planned imports and large workload spikes may need capacity increased in advance.
| Item | Proposed requirement |
|---|---|
| Starting tier | Atlas M20 is the proposed cost-conscious starting tier for a low-traffic, single-client deployment. On Google Cloud, Atlas lists 3.8 GB RAM and 20 GB default storage per node. Confirm the required storage against the migrated database and indexes before provisioning; these are not self-hosted server specifications. |
| Auto-scaling | Enable compute and storage auto-scaling so Atlas can increase capacity as demand grows. Use M20 as the minimum compute tier and agree a maximum tier that permits growth to M30 or higher before launch. Enable downscaling where supported and where the stored data fits the smaller tier. |
| Capacity & cost | Agree storage sizing, scaling settings and budget alerts with Hassan Allam. Scaling changes the bill. Storage growth can require a higher tier and raise the configured maximum, so that maximum is not an absolute spending cap. |
MongoDB production guidance · Atlas auto-scaling guidance · Atlas Google Cloud specifications
MongoDB can run on Hassan Allam’s own infrastructure instead of Atlas. Sakneen connects the application to the agreed replica set and manages the application-level database configuration. These servers host MongoDB only; offer documents and attachments remain in Google Cloud Storage.
| Item | Proposed requirement |
|---|---|
| Deployment | Use Hassan Allam-owned dedicated servers or VMs running a three-node, data-bearing MongoDB replica set. Place nodes on separate physical hosts or independent failure domains; multiple VMs on one physical server do not protect against that server failing. |
| CPU per node | 2 dedicated vCPUs, reserved for MongoDB. |
| RAM per node | 8 GB reserved RAM. |
| SSD per node | 100 GB usable, expandable SSD dedicated to MongoDB data, indexes, journal and replication history. Allocate operating-system disks and backup storage separately. |
| Replica-set capacity | Three nodes require 3 × 100 GB SSD allocations. Each holds a copy of the database, so this is not 300 GB of unique data capacity. Leave room on every node for indexes, operational overhead and growth. |
| Sizing & growth | These figures are a provisional starting allocation, not a measured minimum or a guarantee. Validate existing data, indexes, growth, disk performance, concurrent usage and background jobs before purchase or launch. Hassan Allam resizes servers and storage as needed; Atlas auto-scaling does not apply. |
| Operations owner | Hassan Allam operates the servers and replica set, including server security, OS and MongoDB maintenance, monitoring, backups, restore testing, availability and capacity upgrades. These server operations are outside Sakneen’s scope. |
The client project holds the agreed data services. The application runtime and background workers remain hosted by Sakneen. This project is required with either MongoDB hosting option.
| Item | Proposed requirement |
|---|---|
| Ownership & billing | One project owned by Hassan Allam, with active billing. No buckets, datasets or queues need to be created in advance. |
| Resources in scope | Cloud Storage, BigQuery, Cloud Tasks, Cloud Logging, Cloud Monitoring, and agreed identity and secret-management resources. |
| Offer-file storage | Offer PDFs and attachments stay in Google Cloud Storage, not on the MongoDB server. Proposed planning allowance: 300 GB for 12 months of new offer files, comprising 240 GB calculated usage and 60 GB contingency. Logs, existing files and additional copies are separate. See Storage & retention below for assumptions and exclusions. |
| Provisioning access | Permissions to create and manage the agreed services and their access policies. Any elevated setup access is separately agreed. |
| Ongoing access | A named engineering contact and a separate runtime identity, each limited to its responsibilities. Sakneen will send the identity details securely. |
| Organisation policies | Confirm that approved external identities, required service agents, resource regions and network connections are permitted. |
For Hassan Allam, the proposed offer-file allowance should be sufficient for 12 months of retention at 1,000 offers per month and 20 MB per offer. The calculation below separates file storage, database capacity and logs so that one allocation is not mistaken for another.
| Item | Proposed requirement |
|---|---|
| Workload assumption | One client producing 1,000 offers each month, with 20 MB of retained file content per offer. These are client-supplied planning inputs, not measured file averages. Calculations use decimal units: 1 GB = 1,000 MB. |
| Offer files · 12 months | 1,000 × 20 MB = 20 GB of new files per month; 12 months = 240 GB. A proposed 300 GB GCS planning allowance should cover 12 months at this rate, with 60 GB of contingency (25% above calculated usage). This is an offer-file allowance only, not a measured minimum or a combined files-and-logs allocation. |
| Application logs · 30 days | Propose a rolling 30-day retention period in Cloud Logging, separate from offer files and MongoDB SSD. The inspected shared environment used 30 days for its default log bucket. A single client’s log volume was not isolated, so no GB allowance or combined monthly total is claimed. Measure client-scoped ingestion and retained usage before finalising the log budget. |
| Provider audit logs · 400 days | Google Cloud’s protected _Required log bucket retains its mandatory audit records for 400 days. This provider-controlled period is separate from the proposed 30-day application-log policy and was also confirmed in the inspected environment. |
| MongoDB · separate capacity | The proposed 100 GB SSD per self-hosted node holds database records, indexes, journal and replication history—not offer-file contents. Each of the three nodes stores a database copy. This is a provisional starting allocation; no number of months is verified without measuring the starting database size and subsequent growth. Atlas storage is provisioned and monitored separately under Option A. |
| Additional storage | Existing files imported at launch, regenerated or extra attachments beyond 20 MB per offer, retained object versions, soft-deleted objects, backup copies, activity archives and BigQuery data are outside the 240 GB calculation. Size these separately; the 60 GB contingency is not a guarantee that they will fit. |
The 3 September 2026 inspection checked shared-environment GCS storage metrics, project-wide Cloud Logging ingestion and log-bucket retention settings. It did not isolate Hassan Allam’s file sizes, logs or MongoDB growth, or verify GCS lifecycle settings. Shared usage is not a single-client forecast. The 12-month file policy and 300 GB allowance are proposed planning assumptions; the 30-day and 400-day log settings above were observed in the shared environment, not verified for a new client deployment.
Hassan Allam and Sakneen must approve the retention, recovery and deletion requirements before configuration. Updating this proposal does not change any live bucket, database or retention setting. Database records, business audit history and backups require their own agreed policy; they do not automatically expire after 12 months.
Google Cloud object lifecycle guidance · Google Cloud log retention guidance
Provisioning access and day-to-day application access are separate. We will agree the necessary permissions; unrestricted organisation-wide access is not a prerequisite. Credentials will be exchanged through an approved secure channel.
YOUR DEDICATED DATA ENVIRONMENT
The following are the target destinations after migration and acceptance. Both application records and the supporting operational stores are included in the isolation checks.
| Information | Client-owned destination |
|---|---|
Application records Users, roles, leads, units, projects and organisation settings. | DATABASEYour MongoDB cluster |
Operational application state Background-job payloads and ledger, scheduled-job state, cache, locks, real-time coordination and conversation checkpoints. | DATABASEYour MongoDB cluster |
Reporting and retained history Reporting data and configured audit, activity and completed-job archives. Recent operational history may also remain in MongoDB. | WAREHOUSEYour BigQuery datasets |
Files and documents Media, generated PDFs, retained archive objects and controlled temporary processing files, as agreed for each workflow. | STORAGEYour Cloud Storage buckets |
Background dispatch Queue scheduling and task references. Application job payloads and execution history are held in the dedicated data stores above. | QUEUECloud Tasks in your project |
Application and request logs Delivered to your log bucket under the agreed retention policy. Routing, source exclusions and any other copies are verified before launch. | LOGGINGYour Cloud Logging bucket |
Metrics for your own data services remain with your providers. Application metrics originate in Sakneen’s hosting environment. Client-facing dashboards or exports, alert recipients, uptime visibility and any retained operational copies will be agreed and validated before go-live.
Backups, temporary files and archived records follow the agreed region and retention policy. Document rendering, private-file delivery and all archive destinations are part of acceptance—not only the primary database.
TRANSPARENT BY DESIGN
Dedicated storage is one part of the service. The following processing, identity and operational boundaries will be documented explicitly; they are not a promise that all information stays exclusively inside your accounts.
The application and background workers will run in a dedicated Sakneen-operated environment and process your data to deliver the product. The hosting region and approved network paths will be agreed. If your requirement also covers where processing occurs, we will confirm that before implementation.
Users can continue signing in through Sakneen’s Auth0 identity service. Identity profiles, authentication records and relevant profile metadata remain with that service. Application user records, roles and permissions will reside in your dedicated database. Identity, access and account-lifecycle requirements are confirmed during setup.
Google Cloud’s protected _Required bucket retains mandatory audit logs for 400 days in the project where those records originate. Its retention cannot be shortened. These records can include administrator identities, resource names and action metadata. They are separate from the application and request logs routed to your project.
The application needs authorised access and configuration identifying your resources. We will agree where secrets are held, who can access them and how they are rotated or revoked. Managed or short-lived credentials will be used where supported; long-lived exported keys are not assumed to be necessary for every service.
Analytics, AI and AI tracing, messaging, CRM integrations, document processing, support and monitoring may involve additional providers. Before go-live, each enabled service, account, data category and retention arrangement will be approved. Shared analytics or tracing destinations will be disabled, replaced with client-owned accounts, or explicitly accepted.
Using a client-owned vendor account still involves processing by that vendor. Any such processing remains part of the agreed data-handling scope.
A CLEAR OPERATING MODEL
Hassan Allam owns its infrastructure accounts and data. Sakneen owns the application and operates the resources agreed in scope. The proposed division below will be confirmed in the operating agreement.
A data-layer outage can affect the application. The operating agreement should identify a named owner and escalation route for each dependency.
FROM PROPOSAL TO PROVISIONING
Use this checklist to prepare the infrastructure handoff. Checkmarks are personal planning notes—not confirmation that infrastructure has been verified or the proposal accepted.
SAKNEEN DELIVERY & JOINT ACCEPTANCE
Validate every database, worker, queue, file, archive and conversation-state destination. Unavailable client data services must not trigger a fallback to shared Sakneen storage.
Reconcile records, files, retained history and pending jobs. Agree the migration window and rollback procedure.
Test access denial, isolation, document delivery, log routing, monitoring, approved external services and restore compatibility.
Confirm the operating agreement, named owners, incident contacts and acceptance results before enabling the dedicated production environment.
Confirm your technical contact and the checklist above with your Sakneen contact. We will align the access schedule, agreed scope and provisioning plan before work begins.
Review the requirements