This week’s system design refresher:
Redis Data Structures Every Engineer Should Know
API Security Best Practices
Top 5 Kafka Use Cases
Most Common Types of Cyber Attacks
Continuous Integration, Continuous Delivery, vs Continuous Deployment
Redis Data Structures Every Engineer Should Know

Strings store one value per key. They work for counters, session tokens, and cached payloads.
Hashes store an object's fields under one key. You can update one field without rewriting the rest.
Lists are ordered sequences with fast push and pop at both ends. They fit queues, feeds, and recent-item lists.
Sets hold unique members and support intersection, union, and difference. They cover tagging, follower overlap, and deduplication.
Sorted Sets rank members by a numeric score. They handle leaderboards, priority queues, and top-N or range-by-score queries.
Streams are an append-only log with consumer groups. Each consumer tracks its own position, and the server tracks unacknowledged messages.
JSON stores nested documents with JSONPath access. You can update a field deep in a document without read-modify-write.
Geospatial provides latitude/longitude indexes with radius and box queries. Under the hood it's a Sorted Set with geohash scores.
Vector Set runs approximate nearest-neighbor search over embeddings. It's the retrieval step in most RAG pipelines.
Time Series stores timestamped samples with built-in retention, downsampling, and labels. It fits metrics, telemetry, and IoT data.
Over to you: All ten are built-in as of Redis 8. Which one do you use most outside of caching?
API Security Best Practices
Most API breaches happen because of broken authorization, leaked secrets, or missing rate limits. Let's look at some of the basics.

Use Modern OAuth/OIDC + MFA: PKCE for public clients, short-lived tokens, and step-up MFA for anything sensitive. Implicit and password grants should be dead by now.
Enforce Fine-Grained Authorization: Check object, function, and field-level permissions on every request. BOLA is still the top API vulnerability.
Minimize Scopes and Data: Give each client the smallest token scope and the least data it needs. Only return the fields the caller actually needs.
Encrypt Every Hop: TLS for external traffic and mTLS between services. If it crosses a network boundary, encrypt it.
Protect Secrets and Keys: Store signing keys in HSM-backed vaults. Rotate them.
Validate Requests with Schemas: Reject unknown fields, oversized payloads, and suspicious URLs at the gateway. Don't let bad input reach your business logic.
Rate Limit and Cap Resources: Quotas per user, payload size caps, and execution timeouts. Without these, one misbehaving client takes down your entire system.
Defend Sensitive Business Flows: Protect login, checkout, and OTP with anti-bot, idempotency keys, and step-up auth.
Control Outbound and Third-Party Calls: Allowlist where your API can call out to and block internal metadata endpoints. Your security is only as strong as your weakest integration.
Harden Config and Error Handling: Deny by default on CORS, methods, and debug endpoints. Return generic errors, never stack traces.
Inventory APIs and Versions: Track every endpoint, version, and shadow API. You can't secure what you don't know exists.
Log, Detect, and Respond: Push auth decisions and anomalies to a SIEM. Alert on 401 spikes before they become incidents.
Over to you: Which of these best practices is the hardest to enforce across your services?
Top 5 Kafka Use Cases
System design fundamentals have become more important than ever in the age of AI. Let’s review some of the most popular Kafka use cases today.

Kafka was built for log processing, but now it has been used in other distributed systems for moving events reliably from one system to another.
The log thing is still where most teams start, though. Systems use Kafka for collecting logs from different services and then route them to tools like Elasticsearch and Kibana.
Kafka is also used for streaming user clicks, product events, and ML features that require recent data into tools like Flink.
Another use case of Kafka is to stream performance metrics and system events into monitoring and alerting systems so the teams can catch the issues early on.
Kafka can be used to record database changes into search indexes, caches, analytics tools, or replicated systems.
Kafka helps services to publish and consume events independently, instead of direct service-to-service calls.
Are there any other use cases you have used Kafka for?
Most Common Types of Cyber Attacks

Malware-Based Attacks: These attacks rely on malicious software to infect, steal, or disrupt.
Virus: infects files and spreads when those files are executed.
Worm: self-replicates across networks without user interaction.
Trojan Horse: disguises itself as legitimate software to gain access.
Ransomware: encrypts data and demands payment for decryption.
Spyware: covertly tracks user actions, keystrokes, and sensitive data.
Network Attacks: These target communication channels or network infrastructure.
DDoS: floods servers with traffic, causing downtime.
Man-in-the-Middle: intercepts and alters communication between two parties.
DNS Spoofing: manipulates DNS responses to redirect users to malicious sites.
Web Application Attacks: Focused on vulnerabilities in web apps or APIs.
SQL Injection: injects malicious queries to access or manipulate databases.
Cross-Site Scripting (XSS): injects scripts into webpages to run in users’ browsers.
API Exploits: target insecure or exposed API endpoints.
Identity Attacks: Designed to take over accounts or impersonate users.
Brute Force Attack: automated password-guessing attempts.
Session Hijacking: steals session tokens to act as a logged-in user.
Social Engineering Attacks: These exploit human behavior, not systems.
Phishing: tricks users into revealing sensitive information.
Deepfake: uses AI-generated voice or video to impersonate people convincingly.
Over to you: Which type of cyber attack do you see most often in real-world incidents today?
Continuous Integration, Continuous Delivery, vs Continuous Deployment

Continuous integration: code is built and tested before merging to the main branch, and the artifacts are created, which will be used for staging and production. That artifact is the exact thing that moves forward, so nothing gets rebuilt later.
Continuous delivery: the build is prepared for the release but won't be deployed to production yet. Every good build still goes through staging and the readiness checks first. It will require a human approval or a planned step before it goes live. This is continuous delivery. You'd keep that gate when a release needs sign-off or a heads-up for customers.
Continuous deployment: If you remove the human or process check and the build is directly deployed on the production, then this is called continuous deployment.
Over to you: What does your team's release process look like?
