Syntax Is What You Typed. Systems Are What You Built.

I keep coming back to a line from a pastry chef I saw on TikTok: “Recipes lock you in. Ratios set you free.” He wasn’t dismissing recipes; he was pointing out that recipes are a way in, not a way out. Once you understand how ingredients relate to each other, you can scale batch sizes, work in different kitchens, and different constraints without having to start over every time.

That idea maps cleanly to software, especially once you move past the stage where programming is mostly about getting the syntax right. Early on, syntax dominates your attention because it has to. You learn the language, the framework, the rules of the environment. But as systems grow and responsibilities spread across teams and time horizons, syntax fades into the background and something else takes its place.

That’s when it hit me: Syntax is what you typed. Systems are what you built.

The difference becomes most obvious in cloud-native, serverless work, where the code you write is only a small fraction of the behavior that ultimately shows up in production. The whole promise of serverless was to “write less code” and “focus on the core business logic”. There’s a reason we tell folks that serverless is more than just functions. A function can be correct, well-tested, and easy to reason about in isolation, yet still become part of a system that behaves in surprising or fragile ways under real traffic and usage.

Events and Side Effects

A common serverless pattern is emitting an event when a user signs up, and begins as a simple recipe. A function handles the request, writes a user record, and publishes an event such as UserCreated, after which email notifications, analytics, and account provisioning subscribe to that event independently. The immediate benefits are clear: the signup flow stays focused on its core responsibility, downstream concerns remain decoupled, and new consumers can be added without modifying the original code.

What that recipe quietly establishes, however, is a ratio between autonomy and coordination that only becomes visible over time. As soon as multiple consumers rely on the same event, it starts behaving like a shared contract, even if no one explicitly declared it as one. The event’s schema becomes something other teams depend on, ordering expectations begin to emerge despite not being formally guaranteed, and delivery semantics matter because the system behaves very differently when an event is delivered once, twice, or much later than expected.

‍

At that point, the system is no longer defined by the line of code that publishes the event, but by how the event bus retries delivery, how consumers process messages at different speeds, and how partial failure is handled when one consumer succeeds and another does not. A duplicated welcome email may be inconvenient, while a duplicated billing action can be disastrous, and an analytics consumer that lags behind by minutes may be acceptable while hours of delay may not be. Each consumer interprets the same event through a different tolerance for delay, duplication, and failure, which forces the system to reconcile those differences somewhere outside the syntax.

As the system matures, this reconciliation shows up in idempotency keys, deduplication strategies, schema evolution practices, and shared conventions about what the event represents and what it does not. Changing the event payload, even in small ways, increasingly requires coordination across teams and timelines rather than a simple local code change. The publishing code itself often remains unchanged, while the cost of modifying the system continues to rise.

What began as a clean decoupling mechanism gradually becomes a system shaped by time, retries, partial failure, and human coordination, and that shift is rarely visible in a code diff. It reveals itself instead through operational behavior, incident response, and the growing care required when someone asks, “is it safe to evolve the event?”

Queues, Load, and Reality

Introducing a message queue is another common serverless move that often begins as a straightforward response to load. A service publishes work to the queue, consumers process messages asynchronously, and the system immediately feels more resilient. Spikes are smoothed out, downstream services are protected, and producers are no longer tightly coupled to consumer throughput.

Over time, though, the queue starts to redefine how work flows through the system. Because producers can now outpace consumers, backlog becomes a first-class concept rather than a transient condition. Retry policies, visibility timeouts, and concurrency limits begin to interact in ways that are easy to underestimate when looking only at handler code. A visibility timeout that is slightly too short can cause messages to be processed multiple times in parallel, while an overly aggressive retry policy can quietly multiply traffic and amplify load on downstream systems.

As traffic grows, configuration choices that once felt like tuning details take on architectural weight. Concurrency limits put a cap on how much parallelism the system can safely sustain, while batch size and average processing time largely determine how quickly backlogs drain after a spike. When these settings live outside the application code, they can change system behavior dramatically without any corresponding change in syntax, making cause and effect harder to trace during incidents.

‍

Queues also tend to sit at the boundary between teams. One group may own the producers, another the consumers, and a third the platform that operates the queue itself. When failures occur, responsibility is rarely isolated to a single component, and debugging becomes an exercise in understanding how timing, retries, and backpressure propagate across organizational boundaries. The consumer code may be correct, yet the system still fails because the interaction between configuration, load, and retry behavior creates conditions no individual team explicitly designed for.

What begins as a simple buffering mechanism gradually becomes a system defined by flow control and coordination. The syntax used to enqueue and process messages remains simple and stable, while the true complexity lives in the ratios between throughput, latency, and failure tolerance that shape how the system behaves under sustained pressure.

Storage Shapes the System

Storage choices are a good example of how ratios quietly replace recipes. On the surface, choosing between object storage, a key-value store, or a relational database can feel like an implementation detail, something you can swap later if needed. In practice, each option encodes a set of proportions between convenience, flexibility, and control that shape the system over time.

Object storage often wins because it is easy to access, cheap to scale, and simple to share across services and environments. That ease encourages systems to treat data as whole artifacts rather than individual fields, favoring workflows where data is produced, stored, and consumed independently. The “recipe” is straightforward, write an object and read it back, but the underlying ratio leans toward coarse-grained access and looser coordination.

Key-value stores shift the ratio in a different direction. They trade flexibility for speed by rewarding systems that know their access patterns in advance. When used well, they enable extremely fast reads and predictable performance, but they also encourage precomputed views and denormalized data. The recipe looks simple, fetch by key, yet the ratio moves complexity into the application, which now owns the logic for keeping related values in sync.

Relational databases rebalance those forces again. They emphasize normalization and flexible querying across entities, allowing systems to ask new questions without reshaping all upstream data. Constraints and relationships live close to the data, which can reduce duplication and improve consistency. The recipe for reading and writing rows is familiar, but the ratio favors shared structure and coordinated change, especially as more teams depend on the same schemas.

None of these choices are right or wrong. What matters is recognizing that each one sets a ratio you will live with for years. The syntax to store and retrieve data fades quickly, but the proportions between speed, flexibility, and coordination become part of the system’s shape.

‍

That’s the difference between following a recipe and understanding the ratios. You didn’t just choose where to put data. You choose how your system will handle change.

Across all of these examples, the same pattern emerges. Syntax solves local problems, while systems determine global behavior. The most consequential failures and successes show up in the spaces between components, where timing, retries, and state interact in ways that no single piece of code fully controls.

For tech leads working in the middle of active delivery, this distinction is not abstract. It shows up when changes cross team boundaries, when ownership is shared, and when systems have to keep running while they evolve. Strong system intuition comes from learning to see those interactions clearly and from developing a feel for how small decisions compound over time.

This is also why cloud-agnostic thinking becomes possible once you focus on systems rather than services. Every major cloud offers similar primitives: stateless compute, asynchronous messaging, durable storage, and standardized ways for components to communicate. The names change, and the ergonomics differ, but the underlying behaviors remain. Engineers who understand those behaviors can move between stacks without starting from scratch because they’re not memorizing recipes. They’re reasoning about relationships between components.

For people looking for better answers in cloud engineering and architecture, the work is less about finding the right tool and more about sharpening that kind of intuition. It means paying attention to how systems behave under load and failure, tracing flows end to end, and treating time and state as first-class concerns. It also means sharing that understanding across teams so decisions are made with a common mental model, not just a common code style. What persists is the system you build and the behavior it exhibits long after the syntax has been forgotten, heh, just ask any COBOL dev.

‍

The strongest cloud engineers aren’t defined by the tools they know. They’re defined by how well they understand systems. They can walk into any stack, any cloud, and reason about the same forces: time, load, failure, coupling, and change.

So invest in system thinking. Learn the primitives. Study how real systems behave under stress. Practice designing flows, not just writing functions.

The clouds will keep changing.

The names will keep changing.

Syntax is what you typed.

Systems are what you built.

‍