Data Encryption

Encryption takes plaintext and a secret key, runs them through a math function, and produces ciphertext that looks like random noise. Decryption reverses it using a key. Without the right key, the ciphertext is useless. The strength of the scheme comes from the key staying secret and the algorithm being hard to reverse, not from hiding how the algorithm works.

There are two families. Symmetric encryption uses the same key to encrypt and decrypt; AES-256 is the standard here and it is fast enough to encrypt gigabytes per second on modern CPUs that have AES-NI hardware instructions. Asymmetric encryption uses a key pair, a public key to encrypt and a private key to decrypt; RSA-2048 and elliptic-curve schemes like Curve25519 are common. Asymmetric is slow, so real systems use it only to exchange a small symmetric key, then switch to symmetric for the bulk data. That hybrid pattern is exactly what TLS does on every HTTPS connection.

Encryption at rest protects data sitting on disk, in a database, or in object storage, so that a stolen drive or a leaked backup file is unreadable. This is often transparent. AWS RDS, EBS volumes, and S3 buckets can encrypt every block with AES-256 with one setting, and the application never sees a difference. The database still decrypts on read, so encryption at rest does not protect against an attacker who already has valid database credentials; it protects against theft of the underlying media.

Encryption in transit protects data while it moves across a network so nobody can read or tamper with it on the wire. TLS 1.3 is the workhorse: it does a handshake to agree on a session key, then encrypts the rest of the connection. The same idea covers service-to-service traffic inside a cluster (mTLS between microservices) and replication traffic between database nodes.

A third category, encryption in use, keeps data encrypted even while being processed, using techniques like homomorphic encryption or hardware enclaves such as Intel SGX. It is far slower and still niche, used mostly for highly sensitive multi-party computation.

Encryption is cheap; key management is the real work. If you lose the key, the data is gone forever. If the key leaks, the encryption bought you nothing. This is why teams use a Key Management Service such as AWS KMS, Google Cloud KMS, or HashiCorp Vault, which store master keys in hardware security modules and hand out short-lived data keys. A common pattern is envelope encryption: a data key encrypts the data, and a master key in the KMS encrypts the data key, so the plaintext master key never leaves the HSM.

The costs are modest but real. Symmetric encryption adds a few percent CPU overhead; the TLS handshake adds one network round trip on a new connection, which is why connection reuse and session resumption matter. Encrypted data also does not compress well and you usually cannot run a database index over an encrypted column, so field-level encryption forces awkward choices about what stays searchable.

Rotate keys on a schedule, never hard-code keys in source or config files, and prefer authenticated modes like AES-GCM that detect tampering rather than older modes like AES-CBC used alone.

When you open https://www.systemdesign.academy, your browser and the server run a TLS 1.3 handshake. They use asymmetric crypto (an ECDHE key exchange) to agree on a shared symmetric session key without ever sending it across the wire, verify the server certificate against a trusted certificate authority, then encrypt every byte of the page and your form submissions with AES-GCM under that session key. An attacker sniffing the WiFi sees only ciphertext.

Behind the scenes, the user records that page writes land in a Postgres database on an encrypted EBS volume, and nightly backups go to an S3 bucket with server-side AES-256 encryption whose keys are managed by KMS. So the same data is protected in transit by TLS, then at rest by disk and storage encryption, two independent layers covering two different threats.