Solution scenario

A reference architecture for financial workloads

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.

Primary decision
Planning the intraday and end-of-day bands separately
Protection objective
Backup frequency and retention period
Boundary
Regulatory compliance remains the organisation’s responsibility

Overview

Along which axis does a financial workload split the architecture?

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

One day, two different resource profiles

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

Continuous during the day, batched at day end

  • Transaction flow within business hours
  • End-of-day reconciliation window
  • Two bands, two resource profiles

Data volume

Small daily growth, long retention

  • Transaction dataset on a block volume
  • The day-end copy is backed up
  • Retention set by the institution

Latency and compliance

Latency during the day, traceability at day end

  • Short response time on the transaction path
  • Access record at the network boundary
  • Scheduled backup

The two bands run on separate resource profiles. Retention follows institutional policy, and service level terms follow the contract.

Reference architecture

Two bands with a single data layer between them

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.

Two time bands and a shared data layerIn the upper intraday band the network boundary, the transaction application and the intraday queue sit side by side. The wide strip in the middle is the shared transaction dataset both bands read. In the lower end-of-day band the batch job, the backup copy and the retention vault connect in sequence. The auditable access record on the right attaches to the shared layer with a dashed link.Intraday bandEnd-of-day bandNetwork boundaryRouterTransaction applicationComputeIntraday queueComputeShared transaction datasetBlock StorageEnd-of-day batch jobComputeBackup copyBackupRetention vaultBackupAuditable access recordKept at the boundaryretentionaccess trail
The router draws the boundary between the transaction layer and the exposed surface; the access record is kept at that boundary.

PortvMind Cloud services used

A network boundary, persistent data and retention

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.

  1. Compute

    The intraday transaction application and the end-of-day batch run on separate profiles.

  2. Block Storage

    The shared transaction dataset that both bands read lives here.

  3. Backup

    The day-end copy and retention period are planned with this service.

  4. Router

    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

Band, boundary, retention and requirement

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.

Band, boundary, retention and requirement
CriterionQuestion askedAnswer in this scenario
Time band separationDoes 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 segmentationIs the transaction layer separated from the exposed surface?Yes — the router draws the boundary, and access rules and records are defined there.
Protection objectiveAre backup frequency and retention defined?Frequency and retention are planned in Backup according to the institution’s policy.
Regulatory requirementHow 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

Reading on backup planning and archive migration

Institutional backup planning and archive migration are covered in the guides. API access and operational steps are explained in the documentation.

Guides

  • What Is Cloud Backup? How to Plan Enterprise Backups

    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.

  • S3 Migration Checklist: How to Plan an Object Storage Move

    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.

Other solution scenarios

  • E-Commerce and Retail

    A campaign peak with a known date, an elastic pool and an egress budget.

  • Gaming

    Stateful sessions, the matchmaking decision and asset distribution.

  • Public Sector

    A single controlled entry, nested boundaries and retention of the document archive.

Let us define the two bands and the retention plan together.

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.