- How presigned URL works in case of S3?
NOSQL DB and ACID Traditionally, most **NoSQL databases miss out on the “C” (Consistency) and “I” (Isolation) parts of ACID — especially in **distributed setups**.
Let’s break down where they usually fall short:
🔹 A – Atomicity
- Usually supported at the single-record or single-document level.
- Multi-record atomicity is often not guaranteed unless explicitly supported (like in MongoDB 4.0+ or DynamoDB transactions).
🔹 C – Consistency ✅❌
- This is often relaxed in favor of eventual consistency (especially in distributed systems like Cassandra, DynamoDB).
- The system might allow reading stale or intermediate data to maintain availability and partition tolerance (as per the CAP theorem).
🔹 I – Isolation ❌
- Traditional NoSQL systems often don’t offer strong isolation levels like serializability.
- Concurrent writes might lead to race conditions, unless developers handle it using app-level locks or conflict resolution.
🔹 D – Durability
- Mostly supported, depending on configuration (e.g., write-ahead logging, replication).
- Durability might not be guaranteed if the write hasn’t been persisted to multiple nodes (depending on consistency level).
🧠 Summary Table
| ACID Property | Traditional NoSQL Support | Notes |
|---|---|---|
| Atomicity | ✅ (single entity) | Full ACID for one document or row; multi-entity is tricky |
| Consistency | ❌ (relaxed) | Eventual consistency to boost performance and availability |
| Isolation | ❌ | Weak isolation; dirty reads and write conflicts possible |
| Durability | ✅ (mostly) | Depends on configuration (replication, journaling) |
Let me know if you want this in context of system design trade-offs or how to explain it in an interview — that’s a common area for Microsoft or FAANG interviews.
Base 62 vs Base 64
Here’s a quick breakdown of the difference between Base62 and Base64:
🔢 Character Set
| Feature | Base62 | Base64 |
|---|---|---|
| Characters | 0-9 (10) + A-Z (26) + a-z (26) | 0-9, A-Z, a-z, +, / (or -, _ in URL-safe) |
| Total | 62 characters | 64 characters |
💡 Use Cases
| Base | Common Use Cases |
|---|---|
| Base62 | URL shorteners, compact alphanumeric IDs (safe for URLs and file names without encoding) |
| Base64 | Encoding binary data (images, files, etc.) for transmission over media that handle text (email, JSON, etc.) |
📦 Padding
| Base | Padding |
|---|---|
| Base62 | Typically no padding |
| Base64 | Often uses = padding to ensure output is a multiple of 4 characters |
🧮 Efficiency
- Base64 is more space-efficient when encoding binary data because it utilizes more characters (64 vs 62).
- Base62 is a better fit when only alphanumeric characters are allowed or preferred.
🛡️ URL Safety
| Base | URL Safe? |
|---|---|
| Base62 | Yes, always safe |
| Base64 | No, unless using the URL-safe variant (- and _ instead of + and /) |
TL;DR
- Use Base64 when dealing with binary data that needs to be encoded for storage/transmission.
- Use Base62 when you want short alphanumeric strings (like for URLs or user-friendly IDs) and want to avoid characters that need encoding.
Want to see how encoding/decoding looks in either one with an example?