So far, every tender from TED lands in SQL right away, already parsed. What exactly TED sent is gone afterward. That takes its revenge as soon as the import has a bug: You cannot process a notice again without fetching it again, and you cannot look up what really arrived. From this lesson on, the Kladde first stores every notice raw as a JSON file in Blob Storage and parses it afterward. In module 3.5 this becomes the claim check pattern: The file sits in the blob, and only its name goes through Service Bus.
Besides that, the Kladde gets a second container for offers as PDF, and you learn how to share such a file for 15 minutes without a key showing up anywhere.
Storage account, container, blob
A storage account is the frame: a name that is globally unique (3 to 24 lowercase letters and digits), a region, a redundancy. It
offers several services; this lesson needs only Blob Storage. In it live containers, comparable to top-level folders, and in them blobs,
that is, files. Subfolders do not really exist: A blob is simply named 2025/03/04/123456-2025.json, and tools display the slashes as
folders.
Every blob has an address:
https://<storage-account>.blob.core.windows.net/<container>/<blob-name>
Redundancy
Azure keeps every blob in several copies. How far apart those copies are, you choose with the redundancy:
| Abbreviation | Copies | protects against |
|---|---|---|
| LRS | three copies in one datacenter | failure of a disk or a server |
| ZRS | three copies in three availability zones of the region | failure of a whole datacenter |
| GRS | LRS and, time-delayed, three more copies in the partner region | failure of the whole region |
| GZRS | ZRS and, time-delayed, three more copies in the partner region | both |
Without a prefix, you reach the copy in the partner region only after a failover. With the prefix RA- (RA-GRS, RA-GZRS) you can read it
at any time, even while the primary region is down. The Kladde uses
LRS in dev and test, ZRS in prod. If need be, it can fetch the raw data from TED again; a copy in a second region is not worth it
for that. Write this trade-off down, because lesson 3.6.5 asks about it.
Access tiers and lifecycle
Blobs live in an access tier. The less often you read a file, the cheaper the storing and the more expensive the reading:
| Tier | meant for | minimum duration |
|---|---|---|
| Hot | files that are read often | none |
| Cool | rarely read, available immediately | 30 days |
| Cold | very rarely read, available immediately | 90 days |
| Archive | almost never read; before reading, it must first be rehydrated, which can take hours | 180 days |
Whoever deletes or moves a blob before the minimum duration has passed pays for the rest of the duration anyway. The exact prices per region are shown by the pricing calculator under “Storage Accounts”.
Nobody moves thousands of files by hand. A lifecycle rule does that: It applies to blobs with a certain name prefix and moves or deletes them after a number of days. The rule runs once a day in the background; after you create it, it can take up to 24 hours until it takes effect for the first time.
Versioning and soft delete
With versioning, Azure creates an earlier version of the blob on every overwrite and every delete. With soft delete, deleted blobs and containers are kept for an adjustable number of days. Both protect against your own mistakes: the wrong delete command, the import that overwrites good files. How to get a deleted file back, you practice in lesson 3.6.5. Every version costs storage; that is why the lifecycle rule below deletes old versions after 30 days.