Traffic pattern
Continuous during the day, batched at day end
- Transaction flow within business hours
- End-of-day reconciliation window
- Two bands, two resource profiles
Solution scenario
The intraday transaction flow and the end-of-day batch ask for different resources within the same day. This page shows the two time bands, the shared data layer between them and the retention decision.
Overview
In this scenario the architecture splits along the time axis. During the day the transaction flow is continuous and response time is critical; after hours, reconciliation, reporting and archiving jobs read the same data in bulk. The two bands do not share a resource profile, but they do share a data layer: the transaction dataset sits on a block volume and both bands read from it. The second decision is the network boundary; the router separates the externally exposed surface from the internal transaction layer, and the access record is kept at that boundary. The third is retention: backup frequency and how long copies are kept are planned with Backup. The regulations an institution is subject to — obligations under BDDK, KVKK or MASAK, for instance — shape the requirement side of these decisions; assessing compliance belongs to the institution.
Typical workload profile
Within business hours the transaction flow is continuous and wants a short response time; after hours, reconciliation and reporting read the same data in bulk and want throughput. Daily data growth is modest, yet retention runs long. The profile therefore takes time, not volume, as its main axis.
Traffic pattern
Data volume
Latency and compliance
The two bands run on separate resource profiles. Retention follows institutional policy, and service level terms follow the contract.
Reference architecture
The diagram reads top to bottom as time: the intraday band above, the end-of-day band below, and the transaction dataset both connect to in between. The router stands at the entrance to the band and the access record is kept at that boundary. The backup copy and the retention vault appear inside the same band as separate steps.
PortvMind Cloud services used
The router draws the boundary, Compute runs the work in both bands, Block Storage carries the shared transaction dataset, and Backup owns the day-end copy and the retention vault. What sets this combination apart is that a block volume, not object storage, sits at the centre: the data is not an archive but a transaction set read during the day.
The intraday transaction application and the end-of-day batch run on separate profiles.
The shared transaction dataset that both bands read lives here.
The day-end copy and retention period are planned with this service.
The boundary and access rules between the exposed surface and the internal transaction layer.
Each service page links back to this scenario; the link is generated from the same list in both directions. All Services
Evaluation criteria
The table covers whether the day-end job affects intraday response time, whether the transaction layer is separated, whether the protection objective is defined and how regulatory requirements enter the architecture. The two bands run on separate resource profiles. The retention calendar is planned in Backup according to institutional policy.
| Criterion | Question asked | Answer in this scenario |
|---|---|---|
| Time band separation | Does the end-of-day batch affect intraday response time? | No — the two bands run on separate resource profiles; only the data layer is shared. |
| Network segmentation | Is the transaction layer separated from the exposed surface? | Yes — the router draws the boundary, and access rules and records are defined there. |
| Protection objective | Are backup frequency and retention defined? | Frequency and retention are planned in Backup according to the institution’s policy. |
| Regulatory requirement | How do obligations under BDDK, KVKK or MASAK enter the architecture? | BDDK, KVKK and MASAK are treated as the institution’s architecture requirements. |
Regulation names describe the institution’s architecture requirements. Certificates are issued to vMind Information Technologies.
Related guides and documentation
Institutional backup planning and archive migration are covered in the guides. API access and operational steps are explained in the documentation.
Cloud backup stores scheduled copies of your servers, volumes and application data. With PortvMind Cloud Backup you create, track and restore those copies from the panel. A snapshot is for a fast rollback; lasting protection comes from Backup.
An S3 migration is more than copying files. A controlled move combines source inventory, required API behaviors, metadata and versions, a trial copy, an integrity check, final delta synchronization and a rollback plan. Test the operations your application uses on the target service.
A short access overview and the related product announcement on Discuss.
Practical community guides for GPU, VKE, networking, security and Terraform scenarios.
A campaign peak with a known date, an elastic pool and an egress budget.
Stateful sessions, the matchmaking decision and asset distribution.
A single controlled entry, nested boundaries and retention of the document archive.
Share your transaction volume, your end-of-day window and the institution’s retention policy; in the architecture consultation we plan the network boundary, the data layer and the backup plan together.