DevQuiz

How would you design an API to handle long-running jobs?

@techNmak I've seen databases (MySQL) with UUID as primary keys having over 60M records and read response times around ~20ms. So no that sure about the performance issues.

Random UUIDs are killing your database performance You switched from integer IDs (1, 2, 3…) to UUIDs (a1b2-3c4d-…) for security or distributed generation. Then your database writes get slower, sometimes much slower. Here’s why: Index Fragmentation. Most database indexes are B-Trees (balanced, sorted trees). The physical location of your data matters. 1./ 𝐒𝐞𝐪𝐮𝐞𝐧𝐭𝐢𝐚𝐥 𝐈𝐃𝐬 When you insert sequential integers (1, 2, 3), new data always goes to the rightmost leaf page of the index. Writes are predictable and sequential. Cache hits are maximized. Pages stay 100% full. This is the speed limit of your database. 2./ 𝐑𝐚𝐧𝐝𝐨𝐦 𝐔𝐔𝐈𝐃𝐯4 UUIDv4 values are uniformly random. This means a new insert can land anywhere in the tree structure. Because the inserts are scattered: - The database must constantly load random pages from disk to memory (Random I/O). - Page Splitting => When a target page is full, the database has to split it in half to make room, leaving you with two half-empty pages. - 'Swiss Cheese' Effect => Your index becomes larger and full of holes, wasting RAM and disk space. This can degrade write throughput by 20–90% once your index size exceeds your available RAM. 3./ 𝐔𝐔𝐈𝐃𝐯7 Stop using UUIDv4 for primary keys. Use UUIDv7 (Standardized in RFC 9562). UUIDv7 embeds a timestamp at the start of the ID, making it sortable. This gives you the best of both worlds: - Distributed generation => (No central counter needed). - Monotonic inserts => They behave like sequential integers in a B-Tree, eliminating fragmentation. - Security => Prevents trivial ID enumeration (attackers can't guess that user 101 follows user 100), though note that it does reveal the record's creation time. You get the utility of UUIDs without the performance penalty.

Which is the latest available version of UUID?

@prospercode Golang 😏

2021 – QBasic 2022 – HTML & CSS 2023 – HTML, CSS, JS, PHP, MySQL, jQuery (was busy hating React 😭) 2024 – React, PHP, Python, MySQL 2025 – React Native, React, PHP, Python, Laravel, MySQL 2026 – ??? Every year, I level up. Drop your predictions, what should 2026 be?

@livingdevops And after learning Python, learn Go 😂

Docker is Go. Kubernetes is Go. Terraform is Go. Helm is Go Grafana is Go. Prometheus is Go. Vault is Go. Istio is Go. Etcd is Go. Learn Python before Go for Devops. Because 99% of the time you need to use those tools built in Go, not write them. And Python has way higher adoption for Devops.

@mysticwillz Async processes, they might be failing silently.

You’re in a backend interview. They ask: Your API returns 200, but data never updates. Where do you look first? Here’s the concise answer 👇

@AdamRackis A lot of companies using micro-services use Go.

Man I wish I had a professional reason to learn Go. Backend is all Java at my day job 😐

"And we called it index.php and it...did...*everything*..."

How would you store the records for a TinyURL style service?

@Adarsh____gupta POST for deleting, fetching or updating data

If your API is like this 1. Return 200 OK for errors 2. Have endpoints like /getUser, /createUser 3. Return passwords or tokens in responses 4. user_id, UserId, and idUser in the same response 5. Return null instead of empty arrays 6. { "error": "Something went wrong" } 7. GET /user and GET /users/{id} 8. GET /users?token=abc123 Hell is for you

@makakmayumjava Great sum up!

As a software engineer, learn below to master System Design and build scalable, reliable systems: →Fundamentals a. System components (clients, servers, databases, caches) b. High-level vs. low-level design c. CAP Theorem d. Consistency models (eventual, strong, causal) e. ACID vs. BASE properties f. Trade-offs in design (scalability, availability, cost) →Scalability a. Horizontal vs. vertical scaling b. Load balancing algorithms c. Sharding techniques d. Partitioning strategies e. Auto-scaling and elasticity f. Data replication (master-slave, multi-master) →Reliability & Fault Tolerance a. Redundancy and failover b. Circuit breakers c. Retry and backoff mechanisms d. Chaos engineering e. Graceful degradation f. Backup and disaster recovery →Performance Optimization a. Caching layers (CDN, in-memory like Redis) b. Indexing and query optimization c. Rate limiting and throttling d. Asynchronous processing e. Compression and data serialization f. Profiling tools and bottlenecks analysis →Data Management a. Database selection (SQL vs. NoSQL, key-value, graph) b. Data modeling and schema design c. Transactions and isolation levels d. Data migration strategies e. Big data tools (Hadoop, Spark) f. ETL processes →Networking & Communication a. API gateways and service discovery b. RPC vs. REST vs. GraphQL vs. gRPC c. Message queues (Kafka, RabbitMQ) d. Proxies and reverse proxies e. DNS and CDN integration f. Latency and bandwidth considerations →Security in Design a. Authentication and authorization flows b. Encryption at rest/transit c. Threat modeling d. Access controls and RBAC e. Compliance (GDPR, HIPAA) f. Vulnerability scanning →Architectural Patterns a. Monolithic vs. microservices b. Event-driven architecture c. Serverless and FaaS d. Domain-driven design (DDD) e. CQRS and event sourcing f. Hexagonal architecture →Observability & Maintenance a. Monitoring and metrics (Prometheus, Grafana) b. Logging and distributed tracing (ELK stack, Jaeger) c. Alerting and on-call processes d. SLAs, SLOs, and error budgets e. Versioning and backward compatibility f. A/B testing and feature flags →Case Studies & Best Practices a. Designing URL shorteners b. Social media feeds or notification systems c. E-commerce checkout flows d. Ride-sharing platforms e. Real-time chat applications f. Lessons from outages (e.g., AWS, Google incidents) These will help you architect outstanding systems that scale globally, handle failures gracefully, and deliver high performance under load.

What does the “S” in SOLID stand for?