Understanding Relational Systems in Software

In the software systems we build, understanding the user’s expectations from the system and the interdependencies among integrated systems can be difficult. In this article, we will attempt to understand the set of systems in communication.

Rather than starting directly with software, let us first try to understand the concept by relating it to a real-life situation. Imagine two people in a conversation: one speaks, the other listens. The listener sometimes nods, sometimes narrows their eyes, and sometimes says “hmm” even without fully understanding. Real communication is not limited to speaking the same language; the essential point is sharing the same meaning.

Software systems are just like people. Each performs its own task but must interact with other systems. For example, can an order system exist without interacting with a shipping system? Can user data truly gain meaning without the services surrounding it?

In human relationships, “dependency” usually indicates an unhealthy state. The same applies to software systems. If one module is tightly coupled to another, when the first changes, the second breaks. But complete disconnection is also impossible. Important is to remain connected but not dependent.

• Technical counterpart: A microservice communicates with another microservice through an API or messaging system rather than accessing its database directly. This ensures loose coupling, allowing systems to evolve independently.

Two people may speak the same language but mean the same thing? The same holds true in software. Systems do not merely exchange data; the context, type, timing, and purpose of that data are critically important.

• Human counterpart: Asking someone “Are you okay?” is not the same as understanding whether they truly are. In communication, both parties can derive different meanings from the same question.
• Technical counterpart: When a service sends an OrderCreated event to another, the recipient must interpret it correctly. For the inventory service, this event means “reduce stock”; for the shipping service, it means “prepare shipment”. Each service interprets the event within its own context.

Perhaps the most overlooked element in designing relational software systems is empathy. Empathy requires anticipating the needs, constraints, and workload of another system before designing your own.

• Human counterpart: A good friend senses what you do not say. They can read your emotions from a glance and adjust their communication accordingly, imagining every detail as if they were in your place.
• Technical counterpart: A well-designed system considers the receiver’s speed, capacity, and expected format when sending data. This is not merely technical—it is architectural courtesy. When ignored, both systems fail to function properly; one cannot keep up with the incoming data rate, while the other continues sending, pushing the system beyond its intended purpose and rendering it meaningless to the end user.

^{A representative image showing human communication alongside software algorithms. (Generated by artificial intelligence.)}

Software systems are more than machine-to-machine communication. They are structures designed by humans, operated for humans, and thinking like humans. Building healthy relationships, sending meaningful messages, and designing with empathy extend the lifespan of software and nourish the developer’s spirit. Understanding relational systems is not just about writing better code—it is about learning to build better relationships.

Now let us interpret these concepts technically across different levels of relational systems.

Scenario: Consider three services in an e-commerce system:

• Order Service
• Inventory Service
• Shipping Service

Coupling:

• The Order Service must not directly access the Inventory Service’s database. Instead, it should communicate via an API call or message queue.
• This ensures loose coupling.

Communication:

• When an order is placed, the Order Service publishes an OrderCreated event.
• The Inventory Service listens for this event and reduces stock.
• The Shipping Service also listens for the same event and initiates shipment preparation.

Semantics:

• All services must interpret events within their own context.
• For example, the OrderCreated event means:
• For the Inventory Service: “I must reduce stock for these items.”
• For the Shipping Service: “I must prepare shipment for this address.”

This is an example of semantic interoperability.

Scenario: Separate modules exist within the same codebase:

• User, Product, Order

Coupling:

• The Order module depends on the User module but communicates through an interface.
• It interacts via the UserService interface, keeping internal dependencies under control.

Communication:

• When the Order module creates an order, it asks the User module: “Who is the owner of this order?”

Semantics:

• The User module determines the active user without using data from other modules (e.g., order history). It generates its own meaning internally.

Scenario: There are users and posts tables.

Coupling:

• posts.user_id is a foreign key referencing users.id.

Communication:

• Data is joined using SQL JOIN operations.

Semantics:

• Database relationships directly define the semantic context of data:
• “A post belongs to a user.”

Scenario: A frontend application and a backend API.

Coupling:

• The frontend depends on the backend API’s contract. If the API changes, the frontend is affected.

Communication:

• JSON data is sent and received over HTTP.

Semantics:

• Frontend understands the meaning of data returned by the backend through API documentation (e.g., Swagger).
• status: "shipped" → This product has been dispatched.

Scenario: A banking system

• TransactionCreated event
• FraudDetection, Notification, Analytics services

Coupling:

• The publisher service does not know which services will consume the event.

Communication:

• Message queue (Kafka, RabbitMQ)

Semantics:

• Each service understands the meaning of the event within its own context.
• The TransactionCreated event means:
• Fraud service: Is this a suspicious transaction?
• Notification: Send an SMS to the user.
• Analytics: Update total transaction volume.

Understanding relational systems in software is not only about how systems are connected, but also about understanding how these connections carry meaning. Loose coupling, well-defined interfaces, event-driven thinking, and semantic alignment are the foundational stones of sustainable and scalable systems.

Thank you for reading.