Raul Junco's Linkedin Analytics

I used to overthink which database to choose. I’d get lost in benchmarks, blog posts, and vendor promises...Until I found this simple flowchart. It cuts through the noise and helps you decide based on just two things: - What kind of data do you have? - What are you doing with it? Here’s the gist: Structured + OLTP? → Relational DB Structured + OLAP? → Columnar DB Unstructured? → Object Store Semistructured? Dictionary-style? Use Key-Value or In-memory Lots of relationships? Go Graph Time-based? → Time-series Location data? → Geo DB Nested JSON? → Document Store Search heavy? → Search DB This diagram saved me hours of overthinking. Maybe it will help you too. What’s your default database choice, and when do you switch?

You can memorize patterns and still build systems that fall apart. Because real system design comes in levels. ⬆️level 0 Fundamentals: • Clients send requests • Servers handle logic • Databases store data You learn HTTP methods, status codes, and what a REST API is. You pick between SQL and NoSQL without really knowing why. You're not a backend dev until you've panic-fixed a 500 error in production caused by a missing null check. ⬆️level 1 Master the building blocks: • Load balancers for traffic distribution • Caches (Redis, Memcached) to reduce DB pressure • Background workers for async jobs • Queues (RabbitMQ, SQS, Kafka) for decoupling • Relational vs Document DBs; use cases, not just syntax differences You realize reads and writes scale differently. You learn that consistency, availability, and partition tolerance don't always play nice. You stop asking "SQL or NoSQL?" and start asking “What are the access patterns?” ⬆️level 2 Architect for complexity: • Separate read and write paths • Use circuit breakers, retries, and timeouts • Add rate limiting and backpressure to avoid overload • Design idempotent endpoints You start drawing sequence diagrams before writing code. You stop thinking in services and start thinking in boundaries. ⬆️level 3 Design for reliability and observability: • Add structured logging, metrics, and traces • Implement health checks, dashboards, and alerts • Use SLOs to define what “good enough” means • Write chaos tests to simulate failure • Add correlation IDs to trace issues across services At this level, you care more about mean time to recovery than mean time between failures. You understand that invisible systems are the most dangerous ones. ⬆️level 4 Design for scale and evolution: • Break monoliths into services only when needed • Use event-driven patterns to reduce coupling • Support versioning in APIs and messages • Separate compute from storage • Think in terms of contracts, not code • Handle partial failures in distributed systems You design for change, not perfection. You embrace trade-offs. You know when to keep it simple and when to go all in. What’s one system design lesson you learned the hard way?

Most systems focus on sending reliably. But forget about receiving safely. That’s why: Every Outbox needs an Inbox. In this article, I break down: • What delivery guarantees really mean (at-most, at-least, exactly-once) • How Outbox and Inbox patterns actually work • Where they fail (and how to avoid it) • Visuals + SQL schemas + trade-offs 🎯 Perfect for engineers who build or maintain event-driven systems. Read the full post here: 👇 https://lnkd.in/e_78c8fF Thanks for reading!