Should Microservices Only Talk Through APIs? Or Is It Okay to Read Data Directly?

 

If you’ve worked with microservices long enough, you know this debate never dies:

“Should every interaction between services go through APIs?
Or is it fine if one service reads another service’s data directly—as long as writes go through APIs?”

Some engineers treat API-only communication as a religion.
Others quietly open a read-replica and get on with their day.

The truth?
Like most architectural decisions, the answer is “it depends.”
But there is a sensible middle ground that successful companies naturally converge toward.

Let’s break it down.

---

The Ideal World vs. The Real World

Textbook microservices say this:

“Each service owns its data. No one touches its database. Everything goes through APIs.”

That’s beautiful… but reality is messier.

Real systems deal with:

• High traffic

• Low latency expectations

• Cross-service reporting

• Aggressive SLAs

• Event-driven workflows

• Services that evolve at different speeds

And sometimes, calling an API for every tiny read simply isn’t practical.

But allowing everyone to poke around in each other’s databases?
That’s a recipe for pain.

So how do we balance purity with practicality?

---

Let’s Start With the Easy Rule: Writes Must Go Through APIs

This one is non-negotiable.

Writes carry:

• Business rules

• Validation

• Authorization

• Side effects

• Domain events

If one service writes directly into another service’s database, it’s basically bypassing the “brain” of that system.

That’s how data gets corrupted.
That’s how invariants break.
That’s how midnight outages are born.

So we’re aligned here:

✅ Writes → Always through the service’s API

No shortcuts. No exceptions.

---

Reads, On the Other Hand… Are More Flexible

This is where nuance comes in.

Reads are often:

• High volume

• Latency-sensitive

• Aggregation-heavy

• Used for analytics or dashboards, not transactional logic

And hitting a service API for each read can create:

• Extra hops

• Failure chains

• Scaling bottlenecks

• Increased infrastructure cost

So it’s not surprising that many mature architectures start doing this:

**Use APIs for writes.

Use optimized data sources for reads.**

Yes — that means direct reads can be okay, but only if they’re done safely.

Let’s talk about what “safe” means.

---

When Direct Reads Are Safe

Direct reads don’t mean “connect to the main production database and hope nothing breaks.”

It means using a controlled, read-only source like:

1. Read Replicas

A service might read from a replica of another service’s database, isolated from writes.

2. CDC (Change Data Capture) Pipelines

Using tools like Debezium, Kafka Connect, Dynamo Streams, BigQuery Streaming, or Spanner Change Streams, a service can build a local read model of another service’s data.

3. Search and Analytics Indices

Elasticsearch, Redis, or BigQuery tables built specifically for reading.

4. Materialized Views

A “snapshot” of the data that’s updated asynchronously.

In all of these cases:

• The write service remains the source of truth

• No one is corrupting data

• Schema evolution can be managed

• Performance is optimized

This pattern is basically CQRS, but applied across microservices.

---

When Reads Should Not Be Direct

There are clear cases where you must use APIs and nothing else:

❌ If the read involves business rules

Pricing, eligibility, discount logic — these belong inside the service.

❌ If strong consistency matters

If “inventory = 1 item left,” a stale read can oversell.

❌ If the schema changes frequently

Direct consumers break easily.

❌ If security or PII restrictions apply

You don't want raw access leaking boundary controls.

In such cases, the API is the safe, stable contract.

---

The Architecture Most Companies End Up With

After scaling pains, outages, and refactors, most engineering orgs land here:

⭐ Writes → Always through the service’s API

⭐ Reads → Through a read-optimized, contract-driven data layer

(CDC, replicas, search indices, event streams, or materialized views)

This gives you the best of both worlds:

• Services remain loosely coupled

• Performance improves

• You avoid API call chains

• Schema changes don’t explode downstream systems

• Traffic patterns become predictable

• Teams can work independently

This approach isn’t about breaking microservice purity.
It’s about practical, scalable system design.

---

A Simple Example: Orders vs Inventory

If Inventory needs to check Orders frequently:

Bad: Inventory directly queries Orders’ main database

→ Tight coupling, fragile schema, risk of corruption

Good: Inventory gets a CDC stream or read replica of Orders

→ Local read model, fast queries, no business rule leakage

Writes?

Inventory can update Orders only through Orders’ API.
No exceptions.

Clean. Safe. Scalable.

---

So What’s the Final Answer?

Here’s the human, experience-based conclusion:

**✔ If you’re writing: use APIs.

✔ If you’re reading: choose whatever gives you performance and stability — as long as it’s read-only and contract-driven.**

This is how most high-scale systems operate behind the scenes.
It’s not dogma — it’s pragmatism.

Microservices aren’t about enforcing purity.
They’re about enabling teams to move fast without breaking each other.

And sometimes, that means being flexible about reads while staying strict about writes.

 

🧠 Neo4j Quirks: What You Should Know Before Going Graph

Intro

Neo4j is a powerful graph database, but like any tool, it comes with its own set of quirks—things that can trip up even experienced developers if they're expecting traditional RDBMS or NoSQL behavior. This post summarizes key “gotchas” you should be aware of when adopting Neo4j in real-world applications.

---

1. Relationship Directions Matter (Even When You Think They Don’t)

Neo4j relationships are directed:
(a)-[:FRIENDS_WITH]->(b) is not the same as (b)-[:FRIENDS_WITH]->(a)

Quirk:
When querying, you must match the direction unless explicitly saying otherwise:

MATCH (a)-[:FRIENDS_WITH]-(b) // direction-agnostic

Real-World Impact:
Queries may silently return nothing if you match the wrong direction.

---

2. Large Fanouts Can Kill Performance

What It Means:
A single node with thousands (or millions) of outgoing relationships becomes a performance bottleneck.

Quirk:
Even with indexes, traversals involving large fanouts are slow unless carefully limited.

Tip:
Avoid "celebrity nodes" or batch them with pagination:

MATCH (u:User)-[:FOLLOWS]->(f:User)
WHERE u.name = "Ganapathy"
RETURN f SKIP 0 LIMIT 100

---

3. Indexing Is Not as Granular as SQL

Quirk:
Neo4j indexes work only on node properties, not relationship properties or full-path matches.

Example:
You can't index a path like (a)-[:KNOWS]->(b).

Tip:
Use composite indexes or materialize paths into nodes if needed.

---

4. Orphaned Relationships Are Impossible by Design

Quirk:
You can’t create a relationship without linking it to two nodes.

Good News:
This enforces graph integrity.

Bad News:
You need to clean up nodes and relationships together:

MATCH (a)-[r]->()
DELETE r, a

---

5. Aggregations and COLLECT Can Confuse New Users

Example:

MATCH (p:Person)-[:KNOWS]->(f)
RETURN p.name, COLLECT(f.name)

Quirk:
The COLLECT() function creates lists, but mixing it with non-grouped values can lead to errors or misinterpretation.

Tip:
Always think in terms of how the result should group—Neo4j isn’t a traditional GROUP BY system.

---

6. No Strong Schema Enforcement

Quirk:
Neo4j is schema-optional—labels and property types are not strictly enforced.

Consequence:
You can accidentally insert inconsistent data (e.g., age as string vs number).

Mitigation:
Use CONSTRAINT and ASSERT where possible:

CREATE CONSTRAINT ON (p:Person) ASSERT p.id IS UNIQUE

---

7. Transactions Can Be Subtle in Cypher

Quirk:
Using the browser or driver may hide transactional nuances.

Gotcha Example:
Running CREATE in one query and expecting it to exist in a separate query in the same session may fail if autocommit isn't used.

Fix:
Wrap related operations in a transaction when using the driver:

tx := session.BeginTransaction()
tx.Run(...)
// commit explicitly

---

8. Testing and Cleanup Require Thoughtful Design

Quirk:
Neo4j's test environments don't reset easily unless you clean manually.

Tip:
Create a :TestRun node that relates to all temporary data, and clean it up:

MATCH (:TestRun)-[*]->(n)
DETACH DELETE n

---

✅ Final Thoughts

Neo4j is expressive and great for certain data models—but it’s not magic. Understanding its quirks early helps avoid performance and correctness pitfalls.

Recommended Next Steps:

• Monitor with APOC

• Use EXPLAIN / PROFILE for every query

• Design your data model with traversal in mind

Understanding Read Your Own Writes Consistency in Distributed Systems

Have you ever updated your social media status only to refresh the page and find your update missing? Or modified a product listing that seemingly disappeared into the void? These frustrating user experiences often stem from a crucial concept in distributed systems: Read Your Own Writes (RYW) consistency.

Why RYW Consistency Matters

In my recent DZone article, I dive deep into the world of Read Your Own Writes consistency - a critical yet often overlooked aspect of distributed system design. While technical requirements often focus on scalability and performance, RYW consistency directly impacts how users perceive and interact with our systems.

Think about it: when you make a change to any system, you expect to see that change immediately. It's not just a technical preference; it's a fundamental user expectation that shapes trust in our applications.

Key Challenges in RYW Implementation

Implementing RYW consistency isn't as straightforward as it might seem. In my DZone article, I explore several key challenges:

• Managing complex caching layers across browsers, CDNs, and application servers
• Handling load balancing while maintaining consistency
• Dealing with replication lag in distributed databases

These challenges become particularly evident in real-world scenarios like social media updates, collaborative document editing, and e-commerce inventory management.

Implementation Strategies That Work

The article outlines several practical implementation strategies, including:

• Sticky sessions for consistent request routing
• Write-through caching for immediate updates
• Version tracking to ensure consistency

Each approach comes with its own trade-offs and considerations, which I discuss in detail in the full article.

Want to Learn More?

If you're interested in diving deeper into RYW consistency and learning about specific implementation strategies, check out my complete article on DZone

The article includes code examples, best practices, and monitoring strategies to help you implement RYW consistency effectively in your distributed systems.

Final Thoughts

As distributed systems become increasingly complex, understanding and implementing RYW consistency becomes more crucial than ever. While eventual consistency might be acceptable for some use cases, users expect their own changes to be reflected immediately.

Have you encountered RYW consistency challenges in your systems? I'd love to hear about your experiences in the comments below.

---

This post is a companion piece to my detailed technical article on DZone about Read Your Own Writes consistency. For implementation details and code examples, please refer to the full article.

Striking the Balance: How Companies Can Personalize Without Compromising Privacy

I recently published an article on DataVersity exploring one of today's most pressing digital challenges: how to deliver personalized experiences while protecting user privacy. As someone deeply interested in both user experience and data protection, I found this topic particularly fascinating to research and write about.

Why This Matters Now

We're all familiar with those eerily accurate Netflix recommendations or Spotify playlists that seem to read our minds. But have you ever wondered how companies can provide these personalized experiences while keeping your data safe? In my DataVersity article, I dive deep into this question, exploring real-world examples from tech giants like Apple, Google, and Netflix.

Key Insights

While I encourage you to read the full article for all the technical details, here are some interesting takeaways:

• Local processing on your device can actually deliver powerful personalization without sending sensitive data to the cloud
• Companies like Apple and Google are pioneering innovative approaches like federated learning
• Even streaming giants like Netflix have found ways to provide real-time recommendations while maintaining user anonymity

The Privacy-First Future

What excites me most about this topic is how companies are proving that privacy and personalization aren't mutually exclusive. In fact, as I detail in my article, privacy-preserving approaches might be the key to building deeper user trust and loyalty.

Want to Learn More?

If you're interested in understanding how these privacy-preserving recommendation systems work, including detailed examples and implementation challenges, check out my full article on DataVersity. I explore everything from fine-grained user permissions to anonymous session data handling, complete with real-world applications and future trends.

The full article covers:

• How local models power privacy-friendly recommendations
• The role of federated learning in protecting user data
• Real-time personalization through anonymous session data
• Practical challenges and solutions from major tech companies

The Hidden Backbone of the Internet: Infrastructure, Innovations, and the Future of Connectivity

 Internet infrastructure may seem invisible, but it's a complex web of data centers, fiber-optic cables, IXPs, and cutting-edge technologies. Data centers are the backbone, powering cloud storage and digital communications, while fiber-optic networks act as high-speed highways for data. Internet Exchange Points (IXPs) allow data to be transferred more efficiently between providers, keeping speeds high and reducing latency.

Adding to this are Content Delivery Networks (CDNs) like Cloudflare and Akamai, which cache data closer to users, reducing load and improving response times for data-heavy activities like streaming.

An exciting new frontier in internet access is satellite internet. With Starlink leading the way, low-Earth orbit satellites bring broadband to rural areas, aiming to bridge the digital divide. While these projects face challenges like weather impact and high setup costs, they hold promise for expanding access globally.

Looking ahead, 5G and edge computing are set to boost speed and efficiency. Edge computing, which processes data near its source, will complement 5G’s high-speed, low-latency potential for real-time applications like autonomous driving. Meanwhile, a shift towards sustainable data centers is helping companies reduce the internet's environmental footprint, making the infrastructure more energy-efficient.

With fiber, satellite, and wireless technologies evolving in hybrid models, future internet infrastructure aims to be faster, more resilient, and accessible, catering to the demands of an increasingly digital world.

Stay tuned...

 Hello world,

 Its been a while since I contributed to this blog. 
 Probably now I'm out of the black hole ;) and will keep things interesting here.

 Stay tuned...

Rate Limiting in System Design: Protecting Your APIs and Servers

 With the rise of large-scale applications and APIs, handling excessive traffic is a major challenge. Rate limiting is a crucial technique used to protect systems from abuse, prevent DDoS attacks, and ensure fair resource allocation. In this blog, we’ll explore rate limiting strategies, their implementations, and real-world use cases.

---

1. What is Rate Limiting?

Rate limiting controls the number of requests a client can send to a server within a specified time frame. It helps:
✅ Prevent server overload – Protects backend services from excessive traffic.
✅ Enhance security – Mitigates DDoS attacks and bot abuse.
✅ Ensure fair usage – Prevents a single user from consuming all available resources.
✅ Optimize performance – Ensures smooth operation for all users.

---

2. Common Rate Limiting Algorithms

a. Token Bucket Algorithm

• Each user has a bucket filled with tokens.
• Each request consumes one token.
• Tokens are refilled at a fixed rate.
• If the bucket is empty, requests are rejected or delayed.
  Best for: APIs that require smooth traffic control (e.g., messaging apps, payment gateways).

b. Leaky Bucket Algorithm

• Requests are added to a queue (bucket).
• Requests are processed at a constant rate.
• If the queue overflows, extra requests are dropped.
  Best for: Ensuring a consistent request flow (e.g., video streaming, rate-limited APIs).

c. Fixed Window Rate Limiting

• Defines a time window (e.g., 1 minute) and allows a fixed number of requests.
• If the limit is reached, extra requests are rejected.
  Best for: Simple and predictable rate limiting (e.g., login attempts, API calls).

d. Sliding Window Rate Limiting

• A rolling time window is used instead of fixed intervals.
• More flexible than fixed window since it updates counts dynamically.
  Best for: Preventing bursts while allowing smoother traffic handling.

---

3. Implementing Rate Limiting in APIs

a. Using API Gateways

• Cloud providers offer built-in rate limiting in AWS API Gateway, Azure API Management, and Cloudflare.
• Example: AWS API Gateway allows 1000 requests per second per user.

b. Implementing in Nginx

Nginx provides built-in rate limiting:

nginx
http {
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;
    server {
        location /api/ {
            limit_req zone=api_limit burst=10 nodelay;
        }
    }
}

• Limits clients to 5 requests per second with a burst of 10.

c. Implementing in Redis

Redis can be used to track request counts:

python

import redis
from flask import Flask, request, jsonify

app = Flask(__name__)
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)

RATE_LIMIT = 10  # Max requests per minute
WINDOW = 60  # 60 seconds

@app.route('/api/resource')
def api_resource():
    user_ip = request.remote_addr
    key = f"rate_limit:{user_ip}"
    
    requests = redis_client.incr(key)
    if requests == 1:
        redis_client.expire(key, WINDOW)

    if requests > RATE_LIMIT:
        return jsonify({"error": "Too many requests"}), 429

    return jsonify({"message": "Request successful"})

if __name__ == '__main__':
    app.run()

• Allows 10 requests per minute per IP.

---

4. Real-World Use Cases

🔹 Login Attempt Protection – Limits failed login attempts to prevent brute-force attacks.
🔹 API Monetization – Premium users get higher request limits than free users.
🔹 DDoS Mitigation – Blocking excessive traffic from suspicious IPs.
🔹 Messaging Platforms – Controlling spam by limiting messages per user.

---

5. Challenges & Best Practices

❌ Handling Burst Traffic – Use bursts + gradual rate reductions to prevent abrupt blocking.
✔️ Implement Exponential Backoff – Delay retries for failed requests.
✔️ Use Distributed Rate Limiting – Ensure consistency across multiple servers using Redis or cloud solutions.
✔️ Provide Clear Error Messages – Use HTTP 429 Too Many Requests response with retry hints.

---

6. Conclusion

Rate limiting is essential for protecting APIs, preventing abuse, and optimizing performance. Choosing the right strategy (e.g., token bucket for smooth control, sliding window for flexibility) can help ensure a balanced system.