A communications compliance and archiving provider needed to encrypt and archive messages as part of an information security initiative.

The scale was the hard part: roughly 1,000 messages per second, close to 86 million messages per day.

The encryption primitive was straightforward. The engineering problem sat around it: key-generation volume, vault rate limits, storage metadata, breach investigation, key rotation, and re-encryption cost.

Technogise helped design an envelope encryption model that moved from a per-message key approach to a time-windowed key approach. The design reduced vault requests from about 3.6 million per hour to a handful per hour, while making the larger blast radius explicit and manageable within the client's threat model.

At this scale, encryption becomes a resource-management problem. The design has to survive cost, rate limits, breach search, and recovery operations.

The client needed to encrypt archived messages at high throughput while keeping the system:

• Cost-sustainable
• Operationally recoverable
• Audit-ready
• Executable during incident response
• Practical under vault and KMS rate limits

The target model was envelope encryption:

• A master Key-Encryption-Key, or KEK, protects Data-Encryption-Keys, or DEKs.
• The DEKs encrypt the actual message payloads.
• The KEK sits in a key vault or KMS.

A first design option was to generate a unique DEK for every message. This gives the smallest possible blast radius because one compromised DEK exposes one message.

At roughly 1,000 messages per second, that design also creates roughly 1,000 KMS calls per second for key generation. That becomes expensive and operationally fragile. KMS services charge per API call and enforce strict rate limits, often around 10,000 requests per second across operations. A key-generation surge can throttle unrelated application flows. Even with increased limits, the monthly key-generation bill can exceed the cost of storing the messages themselves.

A unique DEK per message is attractive because it limits exposure. If one key leaks, one message is exposed.

At this message rate, the operating cost becomes the limiting factor.

Roughly 1,000 messages per second means:

• About 3.6 million messages per hour
• About 86 million messages per day
• About 3.6 million key-generation requests per hour in a per-message model

That volume puts continuous pressure on KMS quotas and billing. KMS limits are also shared across key operations. A burst of message ingestion can throttle other encryption, decryption, or rotation tasks.

Technogise treated key generation as a system resource, not an isolated security function. The design needed to protect data while keeping the archive service reliable and affordable.

Technogise designed a model that caches a single DEK for a time window, for example one hour.

At the client's traffic level, that shifts the system from:

• About 3.6 million vault requests per hour

to:

• A handful of vault requests per hour

That decision changes the risk profile. If the hourly DEK leaks, the exposed set can be about 3.6 million records, based on roughly 1,000 messages per second.

Technogise made that trade-off explicit. The design was assessed against the client's threat model and the sensitivity of the archived data. The result was a model that reduced cost and rate-limit risk while keeping the blast radius visible, bounded by time, and auditable.

Encryption design also had to support breach response.

A common pattern is to store encrypted messages in S3 and place the DEK identifier in object metadata. That works for writing and reading single objects. It fails during incident response.

If a key is suspected to be compromised, the team must answer:

• Which messages were encrypted with this DEK?
• Where are those objects stored?
• Which records require rotation or re-encryption?
• How much read/write work will the operation trigger?

S3 object metadata is not searchable at this scale. Finding "all files encrypted with key X" requires scanning the bucket. For an archive handling close to 86 million messages per day, that is slow, expensive, and operationally risky during a breach.

Technogise designed a mapping infrastructure to make key-to-object lookup executable. The mapping links message paths to their DEK IDs in a high-performance database, such as DynamoDB or Cassandra.

That index gives the operations team a direct path from a compromised key to the affected objects.

Key rotation is an I/O problem at this scale.

Rotating keys for millions of messages means reading and writing large amounts of data. The cost depends on storage, indexing, update patterns, and how often the system needs to rotate or re-encrypt.

Technogise evaluated the practical economics of storage and metadata options:

• Postgres can offer cheap storage, but large datasets can run into size limits, such as 32TB, and bulk updates can slow down.
• S3 Tables may offer very low storage cost, but frequent rotation updates can create high I/O fees.
• A high-performance lookup store, such as DynamoDB or Cassandra, can support key-to-message discovery at scale, but the access patterns and write volume must be costed.

The most severe case is master KEK compromise. In that event, the entire archive history must be re-encrypted. At this message volume, a single full-history re-encryption event can cost over $100,000 in compute and I/O.

Technogise sized those paths before the incident happened. That turned master-key compromise from an unknown financial shock into a planned recovery operation.

The designed approach changed the architecture around encryption in six important ways:

1. Key generation became bounded The system no longer needed one key-generation call per message.
2. KMS cost became sustainable Reducing requests from millions per hour to a handful per hour removed the key-generation bill from the critical cost path.
3. Rate-limit risk reduced The archive service no longer placed continuous high-volume pressure on shared KMS limits.
4. Blast radius became explicit The design accepted a larger time-window blast radius and made that trade-off visible to security and engineering stakeholders.
5. Breach search became executable A searchable mapping between message paths and DEK IDs allowed teams to identify affected records without scanning the full object store.
6. Rotation became a costed operation Re-encryption paths, including the master KEK compromise scenario, were sized up front.

Technogise helped the client move from a mathematically clean but operationally expensive per-message key design to a windowed envelope encryption architecture that could operate at roughly 1,000 messages per second.

The result was an encryption design with:

• Far fewer vault requests
• Lower exposure to KMS throttling
• A clear and accepted blast-radius model
• Searchable key-to-object mappings
• Planned rotation and re-encryption paths
• Cost visibility for severe recovery scenarios

For high-volume archives, the secure design is the one the business can operate during normal load and during a breach. This work focused on that operating reality.