Shashank Sati

I've been building SevenDB for most of this year and I wanted to share what we're working on and get genuine feedback from people who are interested in databases and distributed systems.

> what problem we're trying to solve

A lot of modern applications need live data: dashboards that should update instantly, tickers and feeds, systems reacting to rapidly changing state.

Today, most systems handle this by polling—clients repeatedly asking the database “has this changed yet?”. That wastes CPU, bandwidth, and introduces latency and complexity. Triggers do help a lot here, but as soon as multiple machines and low latency applications enter, they get dicey.

Scaling databases horizontally introduces another set of problems:

• Nondeterministic behavior under failures
• Subtle bugs during retries, reconnects, crashes, and leader changes
• Difficulty reasoning about correctness

SevenDB is our attempt to tackle both of these issues together.

> 1. reactive by design

Instead of clients polling, clients can subscribe to values or queries. When the underlying data changes, updates are pushed automatically.

“Tell me whenever this value changes” instead of “polling every few milliseconds”

This reduces wasted work (compute, network and even latency) and makes real-time systems simpler and cheaper to run.

> 2. deterministic execution

The same sequence of logical operations always produces the same state.

Why this matters:

• Crash recovery becomes predictable
• Retries don't cause weird edge cases
• Multi-replica behavior stays consistent
• Bugs become reproducible instead of probabilistic nightmares

We explicitly test determinism by running randomized workloads hundreds of times across scenarios like:

• Crash before send / after send
• Reconnects (OK, stale, invalid)
• WAL rotation and pruning
• 3-node replica symmetry with elections

If behavior diverges, that's a bug.

> 3. raft-based replication

We use Raft for consensus and replication, but layer deterministic execution on top so that replicas don't just agree—they behave identically.

The goal is to make distributed behavior boring and predictable.

> the interesting part

We're an in-memory KV store. One of the fun challenges in SevenDB was making emissions fully deterministic. We do that by pushing them into the state machine itself. No async “surprises,” no node deciding to emit something on its own. If the Raft log commits the command, the state machine produces the exact same emission on every node. Determinism by construction.

But this compromises speed significantly, so what we do to get the best of both worlds is:

On the durability side: a SET is considered successful only after the Raft cluster commits it—meaning it's replicated into the in-memory WAL buffers of a quorum. Not necessarily flushed to disk when the client sees “OK.”

Why keep it like this? Because we're taking a deliberate bet that plays extremely well in practice:

• Redundancy buys durability — In Raft mode, our real durability is replication. Once a command is in the memory of a majority, you can lose a minority of nodes and the data is still intact.
• Fsync is the throughput killer — Physical disk syncs (fsync) are orders slower than memory or network replication. Forcing the leader to fsync every write would tank performance.
• Disk issues shouldn't stall a cluster — If one node's storage is slow or semi-dying, synchronous fsyncs would make the whole system crawl. By relying on quorum-memory replication, the cluster stays healthy as long as most nodes are healthy.

So the tradeoff is small: yes, there's a narrow window where a simultaneous majority crash could lose in-flight commands. But the payoff is huge: predictable performance, high availability, and a deterministic state machine where emissions behave exactly the same on every node.

In distributed systems, you often bet on the failure mode you're willing to accept. This is ours.

> benchmarks

SevenDB benchmark — GETSET
Target: localhost:7379, conns=16, workers=16
keyspace=100000, valueSize=16B, mix=GET:50/SET:50
Warmup: 5s, Duration: 30s

Ops:        total=3,695,354  success=3,695,354  failed=0
Throughput: 123,178 ops/s
Latency:    p50=0.111ms  p95=0.226ms  p99=0.349ms  max=15.663ms
Reactive:   p50=0.145ms  p95=0.358ms  p99=0.988ms  max=7.979ms

I've always wanted to build a startup. I still do.

The first serious attempt came in third year of college, it was e-Vakeel, a legal AI assistant that aimed to make legal help accessible to anyone with a phone. The idea was simple: if someone was stuck in a legal situation, they should be able to get help without spending hours searching through documents or figuring out where to start.

We wanted e-Vakeel to help with things like:

• Drafting legal documents
• Finding similar cases
• Discovering applicable laws and provisions
• Understanding legal procedures
• Getting practical legal guidance

There were three of us working on it, and for several months it completely consumed our lives.

Around that time Ola had just launched Krutrim around Diwali and was giving away ₹10,000 worth of free tokens. We collected accounts from almost everybody in our hostel and ended up with over ₹4 lakhs worth of tokens. Looking back, it sounds ridiculous, but at the time it felt like we had unlocked infinite compute.

We scraped whatever we could get our hands on, applied for data access from Indian Kanoon, scraped them throughout night (their non-busy hours as we assumed), searched through obscure corners of the internet for datasets, contacted everybody who had attempted any such project, got help from a lot of researchers and eventually accumulated over a hundred open and closed datasets related to Indian law.

One thing we quickly realized was that legal judgments are a mess for machines. Before a model can answer anything useful, it first needs to understand which part is a fact, an argument, a precedent or a final ruling.

Not just to answer but also to find similar cases, as we give different weightages for case similarity, for instance, cases with similar facts are far more mutually relevant than cases with similar acts.

For this, we built and annotated a dataset of over 60,000 legal judgments, which translated to roughly half a million labelled data points. Using this dataset, we trained a BiLSTM-CRF model for semantic segmentation of legal judgments and achieved 86.2% accuracy, which as per our research was state-of-the-art for our benchmark at the time.

For response generation, we experimented heavily with reasoning pipelines. This was long before “reasoning models” and “chain of thought” became mainstream terms. We spent an absurd amount of tokens trying different prompting strategies, intermediate reasoning steps, retrieval techniques, and verification flows. At times it honestly felt like we were just burning through tokens for no reason.

Fortunately we were expecting funding from our college incubator, in addition to those collected free tokens, so we weren't too worried about burning through compute while experimenting.

We also met quite a few lawyers and a lot of law students. They were pretty much the only people who could actually use what we were building and give us feedback for free. Some conversations completely changed how we thought about the product. Others made us realise that things we thought were important weren't important at all.

We also arranged for meetings with different US based legal startups, disguised as representatives from our college and wanting to help out students who try startups with their legal compliances to get a taste of what and how they were offering, we received many insights like we got to know how important it was to distribute extensions for docs and MS-word for drafting legal documents.

I had never had so much fun before. There was always something happening. A new dataset. A new model. A new idea. A new feature. A new conversation. Every week felt different. We spent an entire month working on a file manager so that we could also collect context for lawyers from their own documents when they use the chatbot, which we never even shipped. We learnt aws, hosting, how models are deployed locally and used through a tunnel, how we could use our 4 laptop setup for hosting an entire promotional event (which we never did but planned to keep the laptop with the best network card as the load balancer and the rest for model hosting), to fully using cloud. It was all just so much fun. We also had planned the distribution through a whatsapp bot, as meta ai wasn't a thing back then, but when we check the costs that we incurred per query, the unit economics would never sit well.

Eventually, we couldn't make it work but even today, whenever I think about building companies, e-Vakeel is the first thing that comes to mind. It taught me more than any course ever did and it remains one of the most memorable things I've worked on.

e-Vakeel never became the company we hoped it would become, but it will always have a special place in my heart. I still have all the datasets, experiments, models and code sitting around somewhere. I plan to make all the work open source so the next ones trying this, continue from where we left off, I should have already done this by now, but I soon will.