Traffic pattern
A peak with a known date, planned scaling
- Campaign window defined in advance
- Stateless request distribution
- The pool shrinks when the window closes
Solution scenario
A reference architecture for e-commerce and retail traffic
The date of a campaign peak is known; its size is an estimate. This page shows how the fixed public entry point, the pool that grows during the campaign window and the egress budget are set up.
- Primary decision
- How far the pool grows inside the campaign window
- Fixed point
- The public entry address stays unchanged through the campaign
- Budget item
- Outbound transfer of product media is planned separately
Overview
What does campaign traffic expect from the architecture?
What sets this scenario apart is that the peak has a calendar. The campaign date is known in advance, so scaling is planned: nodes are prepared before the window opens and released once it closes. The public address stays fixed through the campaign while the node set behind it changes. Request state is not held on the node. Product images are served from object storage and outbound traffic is budgeted separately. Basket and payment paths are monitored apart.
Typical workload profile
The peak has a date; its size is an estimate
Because the campaign calendar is known, scaling does not have to be reactive. Catalogue volume stays comparatively steady while media traffic rises noticeably at the peak. The most critical axis of the profile is therefore not data volume but when the window opens and closes; the capacity plan is written against that calendar.
Data volume
A steady catalogue, media traffic peaking with the campaign
- Product media in object storage
- Application nodes carry no media
- Egress as a separate line item
Latency and compliance
Latency on the basket path, separation on the payment path
- Distribution driven by health signals
- A fixed public entry address
- Customer data as a scenario requirement
Peak size is planned from the organisation’s own campaign measurement.
Reference architecture
One entry point with a changeable pool behind it
The architecture reads left to right as a fan-out: a fixed public entry, the load balancer and a five-node pool. The last two nodes are drawn dashed; they exist only inside the campaign window. Two links leave the pool to the right — one to product media, the other to the line where outbound traffic is measured.
PortvMind Cloud services used
Five services between the entry and the egress
Floating IP fixes the entry, Load Balancer distributes, Compute grows and shrinks the pool, Object Storage carries the media, and Network Data Transfer makes the egress budget visible. This is the broadest combination of the seven scenarios, because the chain runs from the inbound request all the way to the outbound transfer on a single page.
Floating IP
The public entry address stays fixed through the campaign while the node behind it changes.
Load Balancer
Stateless requests are distributed across the pool according to health signals.
Compute
Pool nodes are added inside the campaign window and removed when it closes.
Object Storage
Product images and catalogue assets are served from here, not from the application node.
Network Data Transfer
The outbound transfer that rises during the campaign window is planned as its own budget line.
Each service page links back to this scenario; the link is generated from the same list in both directions. All Services
Evaluation criteria
Four questions answered before the window opens
The table covers when capacity is prepared, whether the public address stays fixed, whether session state has been moved off the node and where media is served from. Pool size is planned from the organisation’s campaign measurement and the cost calculator.
| Criterion | Question asked | Answer in this scenario |
|---|---|---|
| Scaling timing | Is capacity prepared at the peak or before it? | Before — because the campaign calendar is known, the pool is prepared before the window opens. |
| Entry point | Does the public address change when a node changes? | No — the fixed public entry address is preserved while the node set behind it changes freely. |
| Session state | Is request state held on the application node? | No — state is moved off the node, otherwise traffic spreads unevenly as the pool grows. |
| Media and egress | Are product images served from the application node? | No — media is served from object storage and outbound transfer is budgeted as a separate line. |
Customer data is planned among the organisation’s architecture requirements.
Related guides and documentation
Reading on object storage and the migration checklist
How an object storage architecture is built and which checklist an existing media archive is migrated with are covered in the guides; provisioning and day-to-day operational steps live in the documentation. Pre-campaign preparation is completed by reading the two together.
Guides
- Object Storage Architecture: How It Differs from Block Storage
Object storage keeps data in buckets as independent objects containing the data, a unique key and metadata rather than filesystem blocks. Applications typically access these objects through an HTTP-based, S3-compatible API. Block storage presents a disk volume to a server, where the operating system runs a filesystem or database. The object model is evaluated for media, backups, archives and data lakes, while the block model suits operating-system disks, databases and workloads that need low-latency random reads and writes.
- 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.
Guides
- How-To Guides
Practical community guides for GPU, VKE, networking, security and Terraform scenarios.
- Getting Started Guide
Go directly to the account creation guide on Discuss.
Other solution scenarios
- Gaming
Stateful sessions, the matchmaking decision and asset distribution.
- Public Sector
A single controlled entry, nested boundaries and retention of the document archive.
- Manufacturing and Industry
A one-way bridge between the plant and the cloud, and a peak-free continuous stream.
Let us plan the campaign window together.
Share your campaign calendar, your current ingress design and the size of your media archive; in the architecture consultation we map the pool plan and the egress budget together.