The Missing Layer Between LeetCode and Production Engineering

Backend Engineering Is Mostly Decision Making

When I started working on backend systems, I realized that writing code wasn't the hardest part.
The hardest part was choosing.
Should I use Redis or PostgreSQL?
Should this be synchronous or asynchronous?
Should I introduce a queue?
Should I cache this result?
Should I optimize for simplicity or throughput?
Most tutorials teach implementation.
Real engineering is about making trade-offs.
Two engineers can solve the same problem using completely different architectures, and both solutions can be correct depending on the constraints.

That's the skill I believe is missing from most learning platforms today.

Most platforms teach you how to write algorithms.
Very few teach you how to make engineering decisions.
That's the difference between solving coding problems and building systems.

The Missing Skill

In a coding interview, you're usually given everything you need:

• Input
• Output
• Constraints
• Function signature

Your job is to write the implementation.
Real backend engineering works differently.
You're rarely told exactly what technologies to use.
Instead you're given a problem.

Design a rate limiter.
Build a notification system.
Process one million events per day.
Store user uploads.
And then you have to figure out the rest.
Should you use Redis?
Should you use PostgreSQL?
Should you store files in S3?
Should communication happen through APIs or events?
Should the system prioritize consistency or performance?
These decisions are often more important than the code itself.

The Problem With Learning Backend Engineering

Most learning resources focus on implementation.
They teach:

• How Redis works
• How Kafka works
• How PostgreSQL works But real engineering is deciding when and why to use them. The best way to learn that skill is through practice. The problem is that practicing requires a lot of setup. Before solving a challenge, developers often spend hours configuring infrastructure. By the time everything is running, the original learning goal is gone. ## A Different Approach

Imagine opening a challenge:

Design a notification service for an e-commerce platform.
Available resources:

• PostgreSQL
• Redis
• Object Storage (S3-compatible)
• Queues

• APIs
  No instructions.
  No prescribed architecture.
  No "correct" technology choice.
  Just requirements.
  Your solution might use:

• Redis for temporary state

• PostgreSQL for persistence

• Queues for asynchronous processing

Someone else might choose a completely different design.
Both solutions could be valid.
That's much closer to how engineering works in the real world.

Learning Through Trade-Offs

The goal isn't to memorize technologies.
The goal is to understand trade-offs.
For example:

Rate Limiter: Redis vs. PostgreSQL

Click to see the trade-off analysis

Redis is faster but volatile; PostgreSQL is persistent but slower for high-frequency increments.

Should counters live in Redis or PostgreSQL?
Redis is faster.
PostgreSQL is simpler operationally.
Which one would you choose?

File Processing Pipeline

Should jobs be processed synchronously or asynchronously?
One is easier to implement.
The other scales better.
Which trade-off matters more?

Challenge: Notification Service

Available resources:

• PostgreSQL, Redis, S3, Queues The Goal: Design for 1M events/day.

Should events be stored first and processed later?
Or should requests be handled immediately?
How much reliability do you need?
Every architecture decision comes with benefits and costs.
That's what makes backend engineering interesting.

Why I Started Building Cruscible

I'm experimenting with a platform where infrastructure is already available.
Instead of setting up services yourself, you get access to building blocks such as:

• Redis
• PostgreSQL
• Object Storage
• Queues
• APIs
• Background Workers The challenge isn't figuring out how to install them. The challenge is figuring out when to use them. The goal is not to teach technologies in isolation. The goal is to practice engineering decisions. ## The Goal --- title: "Practice Backend Engineering Like You Practice DSA" published: false description: "Why we need to move beyond implementation and focus on architectural trade-offs." tags: backend, architecture, learning, systemdesign ---

Most platforms teach you how to write algorithms...

The Missing Skill

A Different Approach

The Challenge: Design a notification service for an e-commerce platform.

Learning Through Trade-Offs