Mohit Ranka

Near-real-time is a product promise, not a Kafka cluster

2026-07-16T10:00:00+05:30

“Near-real-time” is often used as a synonym for “we bought a streaming stack.” On GTM data platforms, that confusion is expensive. The product promise is about whether a decision-maker can trust a number in time—not whether an event log is busy. At LinkedIn, the Enterprise Data Platform (EDP) was intended as the governed center for GTM datasets. BI teams on Power BI and Tableau still ran on Hadoop-era batch paths. They already had data. What they did not have was a reason to treat EDP as the path that made GTM analytics true, timely, and durable as legacy pipelines were marked for deprecation. That gap is a product-promise gap.

Near-real-time is a promise about the age of truth a consumer can act on—not a badge for a streaming cluster.

What consumers actually bought

When sales, marketing, or BI stakeholders ask for better data timing, they rarely mean “please introduce a new consumer group.” They mean things like: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

The dashboard does not contradict the operational truth for long.
A GTM metric used in a weekly motion is not secretly a stale extract.
There is one place to stand when two numbers disagree.

Those are promises to named consumers. For us, the critical early consumers included BI engineering and the GTM partners who lived in their dashboards. If those consumers do not move, the platform’s internal latency graphs are cosplay. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

A definition that forces honesty

I use a boring definition: > For dataset D and consumer C, the promise is that the age of usable data at the moment C acts stays inside an agreed bound—under normal conditions—with a clear story when it does not. Unpack it in platform language: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Named dataset — a sales or GTM entity teams recognize, not “the lake.”
Named consumer — Power BI workbook owners, Tableau extracts, revenue analytics—not “downstream.”
Usable — passes the governance and correctness bar, not merely “row arrived.”
Agreed bound — may start as a milestone (“on EDP before deprecation date, with acceptable query latency”) before it becomes a polished SLO.
Failure story — what the business does when the path is wrong: freeze a pipeline, pin a version, staff a war room—not “we’ll check the dashboard Monday.”

If you cannot name D and C, you are not ready to sell near-real-time. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Why “we can already get the data” kills platform promises

The BI objection was rational: existing Hadoop-based jobs still produced outputs. From their seat, migration was risk without immediate upside. So the competing product was not another vendor. It was the legacy batch path that still worked. Near-real-time platforms lose to “good enough yesterday” until:

the old path has an end date,
the new path is staffed for adopters,
query performance after cutover is somebody’s on-call problem.

We treated those as part of the promise design. EDP engineers helped migrate. Connectors reduced friction into Power BI and Tableau. Deprecation deadlines made dual-running finite. Performance work made “governed” not mean “slower.” Streaming could have been part of some paths. It was not the adoption strategy.

Hidden decisions that are actually the product

Where is the system of record?

If EDP and a legacy pipeline disagree, which number is allowed to win in a QBR deck? Until that is explicit, faster pipelines just produce faster arguments. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Is the promise contractual or best-effort?

Deprecating Hadoop paths is a contractual move: the company is choosing a continuity posture. Best-effort “please try EDP” will lose to local convenience forever. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Who pays for fan-out?

Every BI team and every GTM dataset multiplies support surface. Platforms that treat every new consumer as free eventually stop being able to keep any promise. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

What happens during catch-up and cutover?

Migrations create windows where two truths coexist. The product promise must cover the dual-run period—or you will invent tribal knowledge in Slack. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

The shape that worked: phases, not a big-bang bus

The useful architecture picture was organizational as much as technical: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Executive buy-in — GTM data consolidation as strategy, not a side project.
MVP on high-value sales datasets — prove the promise where pain is visible.
Expand across sales and revenue consumers — widen the interface only after the path works.
Broader GTM standardization — reduce snowflake pipelines.
Governance and optimization — make the default path the boring path.

That sequence is how you keep a freshness/correctness promise while the org is still learning to trust the platform. “Put everything on a stream in quarter one” is usually a way to buy complexity before you have consumers. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Questions I ask before approving “let’s go real-time”

Which decision improves if this dataset gets younger—and who makes that decision?
What is the current path’s delay, really (including BI extracts and cache TTLs)?
What dies when we succeed—the legacy job, or only our spare time?
Who is staffed to migrate the first consumers?
What query latency is acceptable in the tools people actually use?
What do we measure weekly that a VP would recognize?

If the answers are all technology choices, the promise is not ready. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Closing

Near-real-time is not a badge for an architecture review. It is a promise about time, truth, and behavior when truth is late. EDP’s lesson was blunt: the company does not get that promise when a platform exists. It gets that promise when critical consumers—here, BI on GTM data—run on the governed path, and the old batch defaults are allowed to end. Build streams when they earn their keep. Build the consumer promise first.

The platform team’s real job is interfaces

2025-11-13T10:00:00+05:30

At LinkedIn, the Enterprise Data Platform (EDP) was meant to be the centralized way GTM teams managed and consumed datasets. On paper, that is a clear platform charter. In practice, a platform is only real when its interfaces get adopted—including by teams that already have a path that “works.” The hard case was BI. Power BI and Tableau teams were still living on Hadoop-based pipelines scheduled for deprecation. They could already get data. EDP was strategically important and still optional in their week. Without them, EDP could not become the source of truth for GTM analytics no matter how good the internals looked. That is an interface problem, not a cluster problem.

Platforms earn leverage when the interfaces other teams stand on are clear, adoptable, and owned.

The interface was “how BI gets governed data”

When platform teams say interface, they often mean API shape or event schema. Here the consumer-facing interface was broader: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

How does a BI engineer get a trusted dataset into a dashboard workflow?
Who pays the migration cost?
What happens to the old path, and when?
Is query performance acceptable the week after cutover?

EDP’s storage format and pipeline elegance did not answer those questions. Until they were answered, BI had no reason to reorder priorities. Lesson: product teams do not consume your architecture diagrams. They consume time-to-success, predictability, and whether the platform team shows up when the path is rocky.

Adoption failed as an org problem first

This was easy to misread as stubbornness. It was incentives. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

BI teams were measured on analytics delivery, not on platform migration.
Legacy pipelines still produced outputs.
Migration looked like unfunded work with downside risk (latency, rework, surprise breakage).
EDP’s long-term governance story was real—and still abstract compared to this quarter’s dashboards.

Engineering alignment inside the data org was necessary and insufficient. Without a business framing, “please adopt EDP” is a favor request. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Executive sponsorship changed the type of conversation

I partnered with senior leaders on the data and BI side so EDP adoption was not a side quest. The useful reframe was not “modernize for us.” It was: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Hadoop paths were going away.
Continuing to depend on them was a continuity risk, not a neutral default.
EDP was the consolidation path for governed GTM analytics—not a nice-to-have alternate store.

That shift moved the discussion from technical preference to operating risk. Platforms that cannot get that sentence said out loud usually stall in permanent pilot mode. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

We lowered the price of yes

Even with sponsorship, asking BI to self-fund a migration would have failed slowly. The decision that mattered operationally: EDP engineers would take migration load—connectors, pairing, performance work—not only publish docs and wish for pull requests. Concretely, that meant: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Pre-built paths into Power BI and Tableau so “get data from EDP” was not a research project.
Shared work on query performance so cutover did not mean slower dashboards.
A migration toolkit and recurring office hours to kill blockers in public, early.
Alignment with sales and marketing stakeholders who depended on the outputs, not only the producers.

This is platform-as-product without the theater: the job-to-be-done was “keep GTM analytics working on a governed foundation,” and we priced the platform to make that job rational. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Deprecation is part of the interface

Enabling a new path without disabling the old one is how companies collect platforms. The adoption plan included the unglamorous half: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Clear deprecation milestones for legacy Hadoop pipelines.
Time-bound dual running where needed.
A definition of done that included turning things off, not only turning EDP on.

Governance is not a slide about ownership. Governance is whether the abandoned path still quietly feeds production dashboards six months later. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

What changed

Within a concentrated push—on the order of a quarter for the BI migration motion—Power BI and Tableau usage moved onto EDP for the scoped GTM paths we targeted. Redundant pipeline surface area could be decommissioned. Freshness and governance improved because fewer competing “sources of truth” were allowed to linger. I care less about the trophy phrasing than about the mechanism: sponsorship + funded migration + forced deprecation + BI-shaped interfaces.

Where EMs earn their keep on platform teams

The technical work was real. The EM job showed up in places that never appear in a system design doc: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Spending team capacity on someone else’s migration so the company’s data model could converge.
Holding a deprecation line when temporary extensions would have been easier.
Making sure performance issues after cutover were our problem, not a gotcha that punished adopters.
Translating platform risk into language executives will prioritize.

Special cases still existed—BI tools always have them—but they were absorbed into connectors and support rituals, not infinite private forks. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Closing

Platform teams love infrastructure. Infrastructure is not the job. The job is to define, evolve, and defend interfaces other teams can build on—including the incentives, migration labor, and deprecation schedule that make those interfaces real. EDP did not become the GTM source of truth when it launched. It became the source of truth when BI could succeed on it, and the old paths were allowed to die.

When I still choose a relational database

2025-03-13T10:00:00+05:30

In 2013 I wrote RDBMS vs. NOSQL? as a pushback against fashion. The fashion changed costumes—document stores, wide-column, NewSQL, "Postgres is fine," "everything in the lakehouse"—but the underlying mistake did not: picking a datastore from a blog post instead of from access patterns and failure modes.

A relational spine is often the boring default until access patterns and failure modes force a different shape.

This is the sequel I would write to myself: when I still choose a relational database in 2026, and when I do not. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

The default remains boring on purpose

My default for a new product backend is still a managed relational database (usually PostgreSQL) with: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Clear schema ownership
Migrations as code
Backups and point-in-time recovery you have actually restored
Connection pooling and boring observability
A plan for read scale that is not "wishful replicas"

Why? Because most products are transactional workflows with relationships: users, accounts, permissions, orders, configurations, audit trails. Relational databases are extraordinarily good at that shape. They also match how humans reason about correctness. If your primary problems are multi-row invariants, ad hoc query flexibility, and operational maturity, starting elsewhere is often self-inflicted difficulty.

When relational is the right call

I lean relational when several of these are true: 1. Strong invariants matter more than infinite write scale.
Money, entitlements, identity bindings, "exactly one active X per Y." If the business invariant is relational, fighting the model is expensive. 2. Query patterns are still evolving.
Early products change questions weekly. A well-modeled schema with indexes beats a write-optimized store that makes new questions painful. 3. The team’s operational muscle is SQL-shaped.
A perfect paper architecture with zero operators is worse than a known system with runbooks. Skills are part of architecture. 4. Multi-entity transactions simplify the product.
Saga forests can be correct. They are also a tax. If a single-node or lightly clustered RDBMS can hold the transactional core, keep the core small and sharp. 5. You need ecosystem gravity.
ORMs, migration tools, BI access, hiring, incident folklore—relational ecosystems are deep. That is not marketing; it is time-to-recovery.

When relational becomes the wrong center

I move work out of the primary OLTP database when: 1. Write throughput or state size exceeds honest vertical + read-replica plans.
Not vanity metrics—measured saturation, vacuum pain, replica lag that product feels, backup windows that scare you. 2. Access patterns are append-heavy and query-narrow.
Event logs, high-volume telemetry, massive multi-tenant time series. Different stores exist for reasons. 3. Fan-out reads need specialized shapes.
Search, graph traversal at scale, feature stores, geospatial at high QPS—often better as derived systems fed from a transactional core. 4. Availability topology requirements outgrow your relational operator model.
Some multi-region active-active stories are possible with modern relational systems; many are still research projects wearing production clothes. Be honest about the topology you can run. 5. Schema flexibility is real, not aesthetic.
Truly heterogeneous documents with little shared query structure can be a poor fit. "We might need flexibility later" is not a requirement.

The architecture that aged best for me

The pattern I trust: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Transactional system of record in relational (or something with equal invariant strength).
Explicit integration events when other systems must react—versioned, owned, documented.
Derived read models for specialized query paths.
Analytical systems for heavy aggregation—do not abuse OLTP as a warehouse.
Clear rules for dual writes — preferably avoid them; if not, make correctness visible.

The relational database is not the universe. It is often the spine. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

A related lesson from platform service boundaries

Not every “monolith vs microservices” fight is a datastore fight—but the same judgment applies. On an EDP self-serve portal, we had a month-long freeze over whether new UI workflows had to live entirely in a monolithic backend or split early for independent iteration. The useful answer was hybrid: keep core platform capabilities where integration and invariants dominate; split fast-changing workflows where deploy independence pays for the seam cost; put metadata in a system designed for lifecycle, not in accidental dual writes. That is the same muscle as choosing a relational spine: optimize for ownership and correctness at the center, derive or split at the edges, refuse fashion-driven rewrites that stop delivery.

What changed since 2013

A few updates to my older self: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Managed Postgres (and peers) are much better. Failover, backups, and scaling knobs improved. That raises the bar for "we need NoSQL to be reliable."
JSON columns done carefully cover many former document-store arguments—without abandoning transactions.
CDC became mainstream. Turning relational truth into streams is a product pattern, not a science fair.
Distributed SQL exists and can be right—but it is still a specialist choice with specialist costs.
Lakehouses ate a chunk of analytics, which is good: stop pretending your OLTP DB is a lake.

What did not change: NoSQL is not a personality. It is a set of tradeoffs around consistency, query power, operational complexity, and scale. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Decision checklist I actually use

Before approving a non-relational primary store: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Which queries and invariants are first-class in v1?
What is the 12-month data size and QPS with ugly margins?
What does multi-row correctness look like, and who enforces it?
How do we migrate schema or access patterns six months in?
Who is on-call, and what have they operated before?
Can we explain the choice in one paragraph without vendor slogans?

If step 6 requires a conference talk, the choice may still be right—but it needs more proof. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Closing

I still choose a relational database when I want correctness, evolvable queries, and operational boredom around the core of a product. I choose other systems when the access pattern or scale curve makes that boredom impossible. The winning move is rarely "pick a side." It is keep a sharp system of record, derive aggressively, and refuse to let fashion rename your requirements. If you want the older, more argumentative version of this stance, it is still here: RDBMS vs. NOSQL?. The industry moved. The need for judgment did not.

Freshness SLOs: the metric product teams actually feel

2024-07-11T10:00:00+05:30

API latency SLOs changed how we run services. GTM data work taught me the sibling idea the hard way: product teams do not experience your job-success chart. They experience a dashboard that is late, wrong, or disagrees with another “official” number. At LinkedIn, BI teams on Power BI and Tableau could already pull data from Hadoop-era batch paths while the Enterprise Data Platform (EDP) was supposed to become the governed center for GTM datasets. Pipelines can be “green” while the business still feels stale or fragmented truth. That feeling is a freshness and trust problem—even when nobody is paging on consumer lag.

Product teams feel freshness as trust in the number—not as job-success charts on a platform dashboard.

Latency is not freshness

A fast dashboard query can still serve an extract that is hours old. A successful batch job can still leave sales and marketing acting on last night’s world. Latency asks: how long did this request take?
Freshness asks: how old is the truth this decision used? If you only measure the serving API, you will celebrate the wrong layer.

Define freshness in the consumer’s language

For EDP-shaped work, a useful definition was: > For a named GTM dataset and a named BI consumer, how old is the data at the moment someone uses it in a dashboard decision—and is it the governed path? That forces specifics: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Dataset — a sales or GTM entity people recognize.
Consumer — a Power BI or Tableau workflow, not “analytics.”
Usable — on the platform you claim is source of truth, not a leftover pipeline.
Age — including batch boundaries and BI-side refresh behavior, not only platform ingest time.

You can formalize that into an SLO later. First you need a sentence a BI lead and a platform EM would both underline. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Promises that change behavior (not charts for their own sake)

On the BI migration, the promises that changed behavior were not abstract percentiles on a poster. They looked like: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Continuity: legacy Hadoop paths had deprecation dates—staying put was a risk posture, not a neutral default.
Funded cutover: EDP engineers helped migrate; adopters were not asked to donate a quarter of calendar alone.
Acceptable query performance after switch — so “governed” did not mean “slower dashboards.”
Finite dual-running — two truths were a migration window, not a lifestyle.

Call those SLOs if your org has the discipline. Call them operating promises if you are still early. Either way, something has to hurt when the promise breaks—attention, prioritization, or the ability to keep the old path alive. I will not pretend every dataset had a polished error budget. What we had was executive visibility, migration milestones, and a definition of done that included turning legacy paths off.

What to measure along a real path

For a BI consumer, time and trust hide in stages: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Source systems and upstream delay
Platform ingest and validation on EDP
Dataset readiness / governance checks
BI tool refresh or extract behavior
Cache and workbook-level assumptions

Teams often discover the villain is not the fanciest processor. It is an extract schedule, a dual pipeline, or a cutover that never finished. Instrument the path your consumers actually use. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Correctness sits beside freshness

Fresh wrong data is worse than slightly stale right data. During migration, dual sources create a special failure mode: two numbers, both “recent,” different owners. Correctness signals that mattered in practice: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Is this dataset on the governed path?
Are legacy feeds still quietly serving production workbooks?
Do critical fields null out or drift after cutover?
Can someone name the system of record when a QBR fights itself?

Freshness without governance optimizes for speed of confusion. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

How we introduced the promise for BI

The sequence that worked was not “roll out SLO framework company-wide”: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Pick the consumer class already on the critical path (BI for GTM).
Make adoption a leadership priority with a continuity narrative.
Staff the migration so the new path is cheaper than it looks.
Put dates on deprecation.
Fix performance issues as platform bugs, not user error.
Only then talk about tightening time bounds dataset by dataset.

If you start with twenty datasets and a perfect taxonomy, you will get a wiki. If you start with one embarrassing consumer journey, you might get a habit. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

The objection we actually heard

“We can already get the data.”
Yes. That is why platform-only arguments fail. Answer with end-of-life for the old path, labor for the new one, and proof that cutover does not degrade the dashboard. “Batch is fine.”
Sometimes it is. Then write a batch promise (“available by time T for the weekly motion”) and still own correctness and deprecation. Batch without a promise is how shadow pipelines live forever.

Closing

Product teams feel freshness as trust in the number. Platforms earn that trust when named consumers run on a governed path, old paths can die, and someone is accountable when the age of truth is wrong. Whether you brand it SLO or operating promise matters less than whether the company can point to dataset + consumer + bound + owner—and whether missing it changes next week’s work.

Saying no as a platform EM without becoming the villain

2023-11-08T10:00:00+05:30

Platform engineering managers do not run out of good ideas. They run out of capacity to say yes to every reasonable request without wrecking the shared system. The skill is not blunt refusal. It is no with a path—specific enough that partners can execute, firm enough that your team is not a free consulting desk. Two nos from EDP work at LinkedIn taught me more than any generic prioritization framework.

A useful platform “no” names the constraint and funds a path—not a silent block.

Why platform “no” feels personal

Product and BI partners are graded on outputs this quarter. Platform teams are graded on leverage, reliability, and whether the company still has one data model next year. When you decline an unfunded migration or a rewrite-shaped preference, it can sound like indifference. Sometimes that critique is fair. Often it is a missing alternative. A villain blocks silently. A partner names the constraint and funds a way through.

Principles I actually use

Company throughput beats local speed. A one-week special case that creates a permanent support branch is not kindness.
A delayed honest yes beats a fake yes. A Jira key without staffing is a lie.
Tradeoffs go in writing the same day. Memory is political; notes are kinder.

Everything below is those three principles in concrete form. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Case A — No to “just adopt the platform”

Request (implied): BI teams on Power BI and Tableau should move to EDP because it is the strategic GTM data platform. Reality: They could already get data from Hadoop-based pipelines. Migration looked like unfunded risk. EDP could not become the source of truth without them. The no: No to a pure mandate without labor—“adopt EDP” as a favor to the platform team. The path:

Executive sponsorship that framed legacy pipeline deprecation as continuity risk, not taste.
EDP engineers assigned to migration work, not only documentation.
Connectors into Power BI and Tableau.
Query performance work so cutover did not punish adopters.
Tooling, office hours, and hard deprecation milestones so dual-running ended.

That package is a no to magical adoption and a yes to an expensive but real interface change. Within a concentrated push (about a quarter for the BI motion we scoped), the migration stuck and legacy surface area could shrink. Pattern: If the consumer has no incentive, your “no” is to unfunded asks; your “yes” is to change incentives and price.

Case B — No to both pure extremes in an architecture fight

Request (implied): Pick monolith or microservices for an EDP self-serve portal—each side sure the other choice was malpractice. Reality: The disagreement went public, ownership collapsed, and delivery froze for roughly a month. The no: No to a binary holy war. No to indefinite debate. No to “loudest critique wins.” The path:

Structured design review with written criteria (scalability, maintainability, speed, ownership).
Time-boxed POCs from both approaches instead of slide wars.
A neutral senior engineer in the room.
Explicit coaching on ownership and influence in 1:1s—not only technical arbitration.
A hybrid decision: core platform capabilities stayed integrated with the EDP backend; more dynamic portal workflows could be separate services; metadata lifecycle centralized (we used DataHub) rather than re-invented.

Execution resumed on the order of a week after the decision landed; the portal followed on a months-long path with real adoption. Pattern: Sometimes the EM’s no is to false dichotomies. The funded path is a hybrid with proofs. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Make yes expensive in the right way

Temporary exceptions will exist—dual pipelines during migration, transitional architecture branches. Price them: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Time-bounded (deprecation date, not vibes)
Owned (named team for breakage)
Visible (on a list leadership can see)
Removable (exit criteria written down)

Free, quiet exceptions are how platforms drown. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Roadmaps are how you say no at scale

One-off negotiation does not survive GTM scope. The EDP sales/GTM program needed an explicit sequence: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Buy-in and prioritization
MVP on high-value sales datasets
Expand across sales/revenue consumers
Broader GTM standardization
Governance and optimization

That roadmap is a machine for “not yet.” Without it, every dataset is an emergency and every emergency is a yes. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Protect the team without hiding behind them

“The team is busy” is weak if you cannot show the math. Better: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Here is committed platform work (migration staffing, deprecation, portal seams).
Here is what we will not staff this quarter.
Here is the escalation if the business wants to reorder.

Take heat in partner forums so individual engineers are not negotiating company priority alone. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Closing

Saying no as a platform EM is stewardship of shared constraints. On EDP, the nos that mattered were: no unfunded adoption, and no architecture theater that freezes delivery. The yeses were expensive on purpose—engineers on migration, connectors, deprecation, POCs, hybrid seams. If partners can see the path, you are not the villain. You are how the company keeps one platform instead of twelve.

Identity systems fail socially before they fail cryptographically

2023-03-08T10:00:00+05:30

When people talk about identity and SSO, they reach for algorithms: token lifetimes, key rotation, SAML vs OIDC, session fixation. Those details matter. In systems I have built and operated, the outages and near-misses that hurt most started earlier—as social and product failures wearing security clothing.

Identity systems often fail first as ownership and session-semantics problems, not as crypto bugs.

Identity is a dependency graph of humans

An identity platform is not only a service. It is: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Who is allowed to grant access
How contractors, partners, and acquisitions show up
What "logout" means across devices and apps
Which team gets paged when login breaks on a Sunday
How quickly a leaver loses access in reality, not in policy PDFs

Crypto bugs are rare relative to misowned workflows. The system can be textbook-correct and still fail the organization. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Failure mode 1: Ambiguous system of record for "who is this person?"

Enterprises collect identities the way rivers collect silt: HRIS, directories, partner IdPs, legacy user tables, support tools that mint exceptions. If you cannot answer "what is the canonical identifier, and who can change it?" you will eventually: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Duplicate humans
Orphan entitlements
Merge the wrong accounts
Build reconciliation jobs that become the real product

SSO does not fix identity entropy. It multiplies whatever model you already have. Design move: pick a primary subject key strategy, document merge/split procedures, and make account recovery a first-class flow—not a Zendesk folklore. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Failure mode 2: Special cases without expiry

Sales needs a demo tenant. Support needs impersonation. A partner needs a long-lived integration user. Security accepts a temporary bypass. Temporary becomes permanent. Permanent becomes unmonitored. Unmonitored becomes the breach path. Design move: every exception has an owner, an expiry, metrics, and a removal plan. Impersonation and break-glass are products with audit trails, not Slack approvals.

Failure mode 3: Logout and session mental models differ by app

Users think "I logged out." Your distributed sessions think "two refresh tokens and a cache entry are still valid." Mobile thinks something else. A partner app never got the memo. This is not merely UX. It is an access-control bug with a friendly face. Design move: define session lifecycle as an explicit cross-app contract. Test logout like you test login. Include shared devices and support scenarios.

Failure mode 4: Rollouts that treat auth like a feature flag toy

Identity changes have asymmetric risk. A broken profile color is annoying. A broken token validation is company-wide stoppage. Yet teams still ship auth changes like UI tweaks: wide rollouts, thin dashboards, no rehearsal of rollback. Design move: progressive exposure, synthetic login journeys per IdP, clear rollback that does not require a hero, and change freezes around known peak login events.

Failure mode 5: Ownership is "security and also platform and also the app"

When login fails, three teams page each other. When it works, nobody funds hardening. Diffused ownership produces brittle reliability. Design move: a single operational owner for the login path, with written dependencies on IdP, DNS, email, device services, and app session layers. Security sets policy; platform runs the path; apps integrate against a stable interface. Blurry RACI is an availability risk.

What good looks like

Strong identity programs I have seen share traits: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Boring standards on the outside (OIDC/SAML done plainly)
Strict internal models for subjects, credentials, devices, and grants
Auditability as a product feature
Recovery and leaver flows tested, not assumed
Customer-visible status when auth is degraded
Load and failure testing of login, not only of core APIs

Notice how little of that is "pick the trendy token format." That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Questions before you add another identity feature

Who is the human-level source of truth?
What is the break-glass path, and who audits it?
How does a user understand their sessions?
What happens to downstream caches on revoke?
Which team’s error budget does login reliability consume?
Can we re-run last quarter’s incidents as game days?

If those answers are soft, new federation features will add surface area, not safety. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Closing

Identity systems do fail cryptographically—and you should hire people who care about that deeply. But if you only harden tokens while leaving ownership, exceptions, session semantics, and rollout discipline vague, you will still fail. They fail socially first: unclear truth, unowned edges, temporary forever, and teams that cannot coordinate under stress. Build the social protocol as carefully as the crypto protocol. Users feel both. Attackers only need one to be weak.

What “led the web launch” taught me about constraints

2022-07-06T10:00:00+05:30

At Postman, “put the product on the web” was not a greenfield rewrite. It was a constraint problem: a desktop-native API tool used by millions of developers, enterprise pressure for browser access, browser security that blocked the old execution model, and a conference date that would not move. I was the engineering manager accountable for cross-functional delivery—architecture choices, security and infra dependencies, product scope, and keeping the team focused when the path was still uncertain. What follows is what that launch actually taught me.

Launching a trusted desktop product on the web is a constraint problem: security, parity, and an immovable date.

We were borrowing trust, not inventing it

Postman already had a reputation. Developers had muscle memory for collections, environments, and the desktop workflow. A weak web surface would not be judged as “v1 of a new product.” It would be judged as Postman getting worse. That constraint changed prioritization: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Core workflow parity beat architectural purity.
Predictable behavior beat clever browser tricks.
Explicit “not on web yet” beat silent missing features.

Trust is spendable once. We treated every launch-day gap as a brand risk, not a backlog curiosity. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

The existing system was a stakeholder

Greenfield essays assume you choose the stack. We inherited runtimes, sync assumptions, offline collaboration expectations, and a large surface area of API tooling behavior. The desktop app was not legacy to be embarrassed about—it was the system of record for how users worked. The hard question was never “can we draw a web architecture?” It was:

What must be reused so results stay correct?
What must be isolated so the browser can ship?
What bugs will the web amplify because usage patterns change?

Treating the existing product as a stakeholder forced interface thinking: web was a new client of a product system, not a parallel fantasy product. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Browser security forced a hybrid execution model

Desktop Postman could talk to the network like a normal app. Browsers cannot. CORS, sandboxing, and the lack of unrestricted local network access were not edge cases—they were the product. We ended up with multiple execution paths, each owning a real constraint: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Browser Agent — run requests directly when the browser is allowed to.
Cloud Agent — execute in a cloud-hosted environment when the browser cannot reach the target cleanly (cross-origin and related limits).
Desktop Agent — bridge the web UI to a local/on-prem network when the user’s world is not reachable from the public cloud.

That hybrid model was the architectural heart of the launch. It was also an organizational heart: security, infra, and product had to agree on what “send request” meant in three different trust domains. If there is one technical lesson I would keep from the project, it is this: when the environment cannot support your old runtime assumptions, make the execution model explicit. Hiding three behaviors behind one button without a design is how you get support chaos.

Launch day is a reliability event

Postman on the Web was announced at POSTCON. Missing the date was not a soft failure mode. That does not mean we shipped fantasy scope. It means readiness was defined as: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

a user journey that worked under real constraints,
a rollout plan that could expand,
and a team that knew what was deliberately later.

We phased capability instead of pretending the first public cut was the end state: start with constrained access patterns, then enable richer API execution, with the cloud execution path continuing to mature after the headline launch. Marketing owns the keynote. Engineering owns the degradation and expansion story. A launch is not a timestamp. It is a reliability event with an audience.

Cross-team coordination was the critical path

The longest pole was rarely a single function. Security, infrastructure, performance, and product had legitimate, conflicting optimization targets. In that environment, “the engineers will figure it out in Slack” is not a plan. What worked in practice: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Executive air cover for dedicated capacity — without it, every dependency team optimizes for their prior roadmap.
A weekly cross-functional sync whose job was unblocking, not status theater.
Written scope decisions — what was in for conference day, what was explicit debt, who owned the follow-through.

My calendar was part of the architecture. Ambiguity multiplies under deadline pressure; decision logs shrink it. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Performance was a product constraint, not polish

API collections can be huge. A desktop WebView habit does not automatically become a good browser experience. Large histories and large collections will punish naive rendering. We invested in boring, necessary work: more efficient history/state handling, lazy loading, virtualized UI for large lists. That work is easy to dismiss as polish until a power user loads a real workspace and the tab melts. Developer products have an unforgiving feedback loop. Users can tell when the runtime is lying, when the UI is papering over cost, and when error messages are decorative. They will also write about it publicly. That is part of the market.

What I would repeat

Write non-goals as carefully as goals. Conference-day success needs a spine, not a vision deck.
Instrument journeys, not only services. “Request failed” is incomplete without which agent path and which constraint.
Rehearse partial failure — auth issues, agent unavailability, dependency brownouts—not only happy-path demos.
Staff the week after launch like it is part of launch. The real traffic pattern arrives after the keynote.
Protect engineers from thrash by batching stakeholder input; panic multiplies bad architectural shortcuts.

What I would avoid

Betting the public launch on an unfinished platform rewrite that is “almost ready.”
Hiding scope cuts inside the word “polish.”
Success metrics only a marketing team can love.
Hero culture that makes the second week impossible to staff.

Impact, carefully stated

We hit the conference launch window. The web surface became a real product path, not a demo—with cloud execution continuing to land on its own schedule. Adoption afterward made the strategic point obvious: users wanted Postman without installing a desktop app first, and the company was no longer only a local-first tool. Exact figures belong in contexts where they can be sourced and defended. The leadership lesson does not depend on a screenshot of a dashboard: the hybrid execution model plus phased delivery was the only way to respect browser constraints without abandoning the desktop product’s trust.

Closing

“Led the web launch” sounds like a milestone. The work was constraint management: borrowed trust, inherited systems, browser security, conference time, cross-team conflict, and performance under real collections. Code expressed the answers. The answers were the constraints we were willing to name early—and the execution model we built so users did not have to understand them all at once.

Incubating 0→1 beside a mature product

2021-06-15T10:00:00+05:30

When I was at Postman, the core product was already the default API client for a huge HTTP/HTTPS world—on the order of tens of millions of developers on desktop. That success created a sharp problem: how do you explore what comes after HTTP without slowing the product everyone already depends on? Postman Labs was our answer: a small unit with a charter to incubate 0→1 work—new protocols and paradigms—without turning every experiment into a core-roadmap hostage situation.

0→1 incubation works when it sits beside a mature product with a real graduation path—not as endless side quests.

The challenge: the market moved past “REST in a GUI”

Developers were increasingly living with: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

WebSockets for persistent, bidirectional sessions
gRPC for efficient, schema-driven service APIs
GraphQL and other non-CRUD shapes of interface

Internally we had ideas. What we lacked was a structured way to validate, build, and kill or graduate them while the core team stayed focused on the desktop product’s quality and scale. Putting every bet into the main feature factory would have meant either: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

starving core reliability and UX, or
shipping “innovation” at the speed of a mature backlog.

Labs existed to refuse that false choice. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Structure for speed (and containment)

We did not invent another feature team with the same process tax as core. Labs was intentionally different: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Smaller team drawn from engineers who already knew Postman’s product DNA.
Less process theater — lean experiments instead of full SDLC cosplay for every spike.
One North Star metric per initiative — a single definition of success so debates stayed grounded.
Explicit separation from core delivery so a failed experiment did not become a multi-quarter core commitment by accident.

Charter in two axes: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Breadth — protocols and shapes beyond HTTP.
Depth — personas and workflows (testing, automation, CI-shaped use) that the HTTP client alone did not own.

Independence was not isolation from users. It was isolation from the wrong kind of backlog pressure. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

A three-phase model that de-risked 0→1

Every Labs initiative had to earn the next phase: ### Phase 1 — Feasibility and market validation Customer conversations, lightweight proofs, honest “who hurts without this?” If the answer was only “it would be cool,” it did not proceed. ### Phase 2 — MVP and dogfooding Internal builds used by Postman’s own engineers. Usability and correctness issues showed up before a public audience. ### Phase 3 — Limited beta and public validation Constrained rollout, measure adoption and engagement, then decide: graduate into the main product, iterate, or stop. That sequence sounds obvious. The discipline is stopping between phases. Core roadmaps often skip phase 1 and call a half-built feature a launch.

WebSockets: persistent sessions are not “requests with extra steps”

WebSockets were an early Labs bet because real-time systems (chat, feeds, IoT-style control planes, live tooling) do not fit the request/response mental model Postman had optimized for. Hard parts: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Long-lived bidirectional connections instead of discrete calls
Auth flows that must hold for a session, not only a single hit
UX for streams of events over time, not one response panel

What we built toward: a first-class WebSocket client experience—connect, send/receive, inspect event history, support practical auth patterns. Outcome: WebSockets did not stay a lab toy; support graduated into Postman’s broader API development surface. That graduation path was the point of Labs. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

gRPC: schemas and streams in a product trained on text HTTP

gRPC was growing fast in backend-heavy environments. Postman’s muscle memory was text-centric HTTP. gRPC forced different questions: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

How do users work with Protobuf contracts inside the product?
How do unary and streaming calls show up in a composer UX?
How do serialization mistakes become debuggable instead of opaque binary pain?

Execution themes: schema-aware composition, streaming-aware request/response handling, and making “what did I just send?” inspectable for developers who live in Postman daily. Outcome: gRPC testing/debugging became a real product capability in the same family as REST workflows—not a separate science project users had to leave Postman for.

What scaled beyond the first bets

When early graduates worked, Labs stopped being only a temporary squad. The incubation pattern—validate, dogfood, beta, graduate—became a reusable company muscle. Later product bets (including automation-shaped work such as Flows-class ideas) could reuse the same organizational shape: explore beside core, then merge what earns users. Eventually Labs-shaped work attracted clearer funding and leadership attention. That is the healthy end state: not a permanent rebel base, but a proven path for 0→1 inside a company that also has to protect a mature product.

What I would repeat as an EM

Separate exploration capacity from core SLA capacity — or core always wins and innovation becomes slideware.
One success metric per bet — multi-metric dashboards hide kill decisions.
Dogfood before marketing — especially for developer tools; your engineers are harsh, useful users.
Graduation criteria in writing — “done in Labs” must mean something operationally.
Protect the team from identity crisis — Labs is not “the people who do side quests”; it is a product strategy role.

What I would avoid

Innovation theater with no kill switch
Hiding Labs work so core is surprised at graduation
Measuring success only by launches, not by retained use
Staffing Labs only with people core “can spare” forever

Closing

Incubating 0→1 beside a mature product is a leadership design problem: process, incentives, and graduation rules—not only prototype velocity. Postman Labs worked when it had a narrow charter, phased validation, and a path for WebSockets, gRPC, and similar bets to become real product surfaces without forcing the entire company to pretend it was still a startup with nothing to lose. If your core product is already loved, that is not a reason to stop exploring. It is a reason to explore on purpose.

How I review a distributed design in 45 minutes

2021-03-03T10:00:00+05:30

The most expensive design reviews I have run were not missing a box on a diagram. They were missing a decision. One of them froze delivery on an EDP self-serve portal for about a month while two strong engineers disagreed in public about monolith versus microservices—and ownership quietly collapsed. This is how I run a distributed design review when time is short, using that conflict as the worked example. The forty-five minutes are a filter for danger and indecision, not a substitute for deep design.

A short design review is a filter for clear promises, truth models, and decisions—not a theater of diagrams.

The situation the review had to unstick

We needed a self-serve portal on top of the Enterprise Data Platform: dataset registration, governance controls, access workflows, metadata—so teams could manage lifecycle without filing tickets into oblivion. Two credible positions formed: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Stay close to the monolithic EDP backend — simpler integration, less duplication, faster delivery on shared infra.
Split into microservices early — independent iteration on portal features without waiting on the monolith.

Both sides had technical merit. The failure mode was social: critique moved into open forums in a way that undermined the owner, the owner disengaged, and execution stopped. Stakeholders saw silence. That is a design-process failure, not only an architecture debate. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Minutes 0–5: What user promise are we keeping?

Before hexagons, I want one paragraph: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Who uses the portal?
What can they do without a human intermediary?
What is explicitly out of scope for v1?

For us: GTM/data producers and consumers managing dataset lifecycle—registration, access, metadata—not “rebuild EDP as microservices.” If the promise is fuzzy, stop. Architecture will invent scope. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Minutes 5–15: Where does truth live?

I care about systems of record more than service count. Questions that mattered on the portal: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Which actions must be consistent with core EDP backend behavior on day one?
Which workflows change weekly and need independent deploy cadence?
Where does dataset metadata live so the portal is not a second brain?

We eventually used a hybrid truth model: core platform capabilities stayed integrated with the existing EDP backend; more dynamic workflows (access requests, tagging-style features) could stand as separate services; metadata was centralized with a system fit for dataset lifecycle (in our case, Apache DataHub) so the portal was not inventing yet another catalog. Red flags in any review:

“Both systems will stay in sync” with no mechanism.
Every feature forced into one deployability story.
Metadata treated as a UI detail.

Minutes 15–25: What fails—technically and organizationally?

Classic distributed questions still apply: timeouts, dual writes, partial deploy, replay. On this project the binding failure was different: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

What happens if the owning engineer stops driving?
What happens if disagreement becomes a public referendum every week?
What happens if leadership hears only one side’s framing?

A design review that ignores ownership and decision rights will produce a beautiful diagram and a still project. I schedule the technical argument inside a structured forum with criteria—not in drive-by threads. If you need blame-free space, create it deliberately. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Minutes 25–35: How will we choose without infinite debate?

Opinion without evidence burns weeks. The intervention that worked: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Write evaluation criteria before picking a winner: scalability, maintainability, delivery speed, long-term ownership.
Force small proofs — both approaches get a time-boxed spike/POC against the criteria.
Bring a neutral senior engineer into the room to pressure-test both sides without owning either ego.
Time-box the decision — the review ends with a path, not a sequel meeting.

This is operability of the decision, not only of the service. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Minutes 35–40: People side (do not skip)

Distributed design is done by humans with status and career goals. In parallel with the technical path: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Rebuild ownership with the engineer who had stepped back—silence is not an acceptable escalation strategy.
Coach the critic on influence: staff-level impact includes how you challenge, not only that you are right.
Make expectations explicit in 1:1s so the project is not a proxy war.

Skip this and the hybrid architecture will still die in the next disagreement. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Minutes 40–45: Decision and conditions

We did not pick a pure monolith or a pure microservice rewrite. We picked a hybrid: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Core platform features (registration, governance controls tightly bound to EDP) stayed where integration cost dominated.
Dynamic portal features that needed independent iteration moved toward separate services.
Metadata lifecycle was centralized rather than re-implemented.

Approve with conditions, in writing: what is in v1, what is explicitly later, who owns the seams, when the next review is if assumptions fail. Verbal “sounds good” evaporates. Written conditions survive contact with calendars. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

The diagram I want if I only get one

Trade three layered architecture posters for either: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

a sequence of one user action through registration → metadata → access, or
a side-by-side POC scorecard against the agreed criteria.

Sequence diagrams and scorecards reveal lies that box diagrams hide. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Anti-patterns this freeze taught me

Public architecture criticism that bypasses the owner.
Binary holy wars (monolith vs microservices) without workload specifics.
Design review as spectator sport for leadership without a decision owner.
EM waiting too long to facilitate because “they’re seniors, they’ll figure it out.”
Approving to end discomfort rather than risk.

What unblocked looked like

Once criteria, POCs, and a hybrid decision landed, the freeze broke quickly—on the order of a week to resume real execution—and the portal shipped on a timeline measured in months with meaningful adoption. The architecture mattered. The restored ownership mattered more. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Closing

In forty-five minutes you will not finish a distributed design. You can learn whether the team has a clear promise, a coherent truth model, a way to decide, and a human ownership path. On platform work, the last item is not soft. It is how delivery fails first. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Introducing on-call without burning the team

2020-11-10T10:00:00+05:30

At Postman, my team owned a large-scale platform surface used by millions of developers. What we did not own—formally—was a predictable operational response. Production issues and public GitHub noise were handled ad hoc. Someone jumped in, or everyone hesitated. Retrospectives lacked a clear accountable role. The system worked until it did not, and then it worked by heroics. We needed on-call. We also needed engineers who still wanted to build product after the rotation.

On-call is a product and staffing design: clear ownership without making heroics the default.

What was broken before process

Without a rotation, four things piled up: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Unclear ownership — incidents waited on “who feels responsible today.”
Context-switch tax — feature work and firefighting shared the same brains without boundaries.
Uneven load — the same people always raised their hands.
Weak learning loops — retros had symptoms, not a role that carried fixes week to week.

For a developer-facing platform, user-visible breakage is not a side channel. It is the product. Treating ops as optional was a product decision, whether we admitted it or not. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Design goals

I wanted a system that was: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Explicit — someone is primary, always.
Fair — load rotates; it does not stick to volunteers.
Bounded — on-call is a job for a window, not a personality type.
Educational — the whole team sees production, not only a martyr subset.
Humane — no permanent page-from-bed culture dressed up as commitment.

Reliability that depends on burnout is just deferred attrition. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

The model we ran

Primary and secondary

Primary — dedicated to monitoring, incident response, and triage (including GitHub-facing noise). Feature delivery expectations drop for that window on purpose.
Secondary — backup for major incidents; not a stealth second primary for every ping.

If primary is still expected to hit the same sprint commitments, you do not have on-call. You have theater. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Two-week shifts with a handoff pattern

Engineers rotated on a two-week cadence. A common pattern was primary one window, then secondary the next—so knowledge transferred and no one lived forever in the blast radius. Back-to-back primary stretches were treated as a smell, not a badge. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Handoff as a team ritual

Weekly team time included an on-call handoff, not only standup status. Primary walked through: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Incidents and resolutions
Adjacent system issues that might hit us next
Notable GitHub / support themes
Follow-ups that needed owners beyond the shift

That ritual turned private pager pain into shared product knowledge. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Retros and playbooks

Major incidents got structured retros. Recurring issues earned playbooks—step-by-step paths so the next primary was not rediscovering folklore at 1 a.m. Playbooks are how on-call becomes a team asset instead of tribal knowledge in one engineer’s head. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Psychological safety and load management

No expectation of endless consecutive primaries.
Balance with feature work across the quarter so people are not typed as “ops only.”
Managers (me included) treated page load and fairness as staffing concerns, not only engineer grit.

What improved

With clear ownership: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Faster response — we saw on the order of a ~40% reduction in incident response time once roles were unambiguous (directionally; treat it as an order-of-magnitude win from process, not a lab result).
More systematic triage — fewer “is anyone looking at this?” gaps.
Better morale — predictable pain beats random pain.
Broader operational skill — more engineers touched production reality.
Earlier fixes — primaries had space to chip at known sharp edges before they became SEVs.

Stability improved because response became a designed system, not a personality contest. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

What I would tell another EM before day one

Write who is primary in a place the team actually looks.
Cut feature load for primary or you will train people to ignore the pager.
Ship handoff and playbooks in the first month, not after the third outage.
Measure response and fairness, not only uptime.
Defend the rotation against “just this once” exceptions from leadership—exceptions are how volunteers reappear.

Failure modes to avoid

On-call as punishment for the least political engineers
Secondary as free extra primary
Retros without owners or due dates
Alert noise so high that everyone mutes everything
Celebrating heroes instead of fixing the systems that required them

Closing

Introducing on-call is not a tooling purchase. It is a product and staffing decision: user trust requires an accountable human path, and that path must be sustainable. At Postman, primary/secondary roles, two-week rotations, handoffs, retros, and playbooks turned operational ownership from ad hoc heroics into something the team could carry—and still ship. If your platform is already large and your response is still “whoever notices,” you do not have a reliability gap only. You have a leadership design gap. Close it on purpose.

GTM datasets need data contracts

2020-07-01T10:00:00+05:30

When a go-to-market dashboard is wrong, nobody says “the warehouse is eventually consistent.” They say the number is wrong—and they stop trusting the platform. On LinkedIn’s Enterprise Data Platform (EDP) work, the failure mode was rarely a missing chart type. It was informal truth: datasets without clear producers, consumers, freshness expectations, or a path that BI could rely on when Hadoop-era pipelines still “worked.” That is a data-contract problem, whether or not you use the word contract.

GTM datasets become trustworthy when producers and consumers share explicit contracts—not informal folklore.

The contract is the product boundary

A data contract is a written agreement between people who produce a dataset and people who depend on it: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

What the dataset means (grain, keys, critical fields)
Who owns changes
How fresh and complete it must be for its main consumers
Who may use it, and for what
What happens when the shape changes
Which path is the system of record when two feeds disagree

Without that, you have tables and jobs—not a product interface. EDP’s strategic job was to become the governed center for GTM data. BI teams on Power BI and Tableau did not move because a platform existed; they moved when the interface of getting trustworthy data became clearer, cheaper, and eventually mandatory as legacy paths aged out.

Which GTM datasets need contracts (almost all that matter)

Definitely: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Pipeline and revenue metrics that show up in leadership reviews
Account, lead, and opportunity-shaped datasets used across tools
Any feed BI materializes into workbooks that drive weekly motions
Datasets used for access decisions, eligibility, or customer-facing ops
Shared “golden” entities multiple teams join in different ways

Lighter-weight is fine for: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Truly exploratory sandboxes with no production consumers
One-off extracts with an explicit expiry

If a number can start an argument in a QBR, it deserves a contract. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

What we needed in practice (not a 40-page template)

Keep contracts short enough that producers and BI partners will read them: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Dataset name and owning team
Grain (what one row means)
Critical fields and allowed null behavior
Primary consumers (e.g. Power BI / Tableau paths, sales analytics)
Freshness / readiness expectation — even if it starts as “available on EDP before legacy deprecation,” not a perfect percentile
Change policy — notice, versioning, who approves breaking changes
System of record during dual-run periods
Support path — where breakages go (not a random Slack thread)

On EDP, connectors, migration staffing, and deprecation dates were how contracts became real. A wiki table alone does not change incentives. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Why platform adoption without contracts fails

BI’s rational objection was: “We can already get the data.” Informal sources always feel free until: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Two dashboards disagree
A legacy pipeline is turned off
A field changes meaning and nobody tells the workbook owner
Query performance after cutover becomes “the platform’s problem” with no owner

Contracts force those conversations before the incident. They also make deprecation fair: you cannot retire a path nobody documented as non-authoritative. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

Evaluation is part of the contract

Do not separate “data quality” from “dashboard quality.” Ship and migration gates should include: That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Consumer path checks (does the BI workflow still resolve?)
Row-count / null-rate sanity on critical fields
Explicit dual-run comparisons while both paths live
A named human who can freeze a bad publish

When the contract breaks, something visible should fail before the QBR does. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Organizational pattern that worked

Producers own correctness and change communication
Platform (EDP) owns enforcement, discovery, access patterns, and migration leverage
BI / analytics partners own consumer semantics and workbook impact
Leadership owns deprecation as continuity policy, not a style preference

Shared Slack channels are not a substitute for ownership. Funded migration and executive sponsorship were how EDP contracts left the slide deck. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams.

A sequence I recommend for new GTM datasets

Write the decision the dataset supports in one sentence.
Name the first production consumer (often a BI path).
Draft the contract before scaling access.
Put the dataset on the governed platform path.
Dual-run only with an end date.
Turn off the informal path.

Teams love to start at “expose the table.” Steps 1–3 are where trust is designed. That detail matters in practice because the surrounding system, incentives, and failure modes usually determine whether the idea survives contact with production and with other teams. I treat this as an operating constraint rather than a slogan: if you cannot explain how it shows up in ownership, metrics, and day-to-day decisions, it will not survive the next roadmap fight.

Closing

EDP did not earn “source of truth” status by existing. It earned it when GTM consumers—especially BI—could depend on named datasets with owners, expectations, and an end to competing pipelines. Call that a data contract, a product interface, or an operating promise. Just do not ship GTM data as folklore and hope governance appears later.

RDBMS vs. NOSQL?

2013-06-29T00:16:00+05:30

From our own experience designing and operating a highly available, highly scalable ecommerce platform, we have come to realize that relational databases should only be used when an application really needs the complex query, table join and transaction capabilities of a full-blown relational database. In all other cases, when such relational features are not needed, a NoSQL database service like DynamoDB offers a simpler, more available, more scalable and ultimately a lower cost solution.

            — Werner Vogels, CTO Amazon.com on when to use RDBMS

Datastore choice is a tradeoff about access patterns and operations—not a fashion contest.

I came across this quote in an article while researching DynamoDB. As much as I respect Werner, I would suggest take his recommendation on the criteria on database selection with a pinch of salt, due to the obvious conflict of interest — He has a database to sell.

Most products do not need the scale, which cannot be served by relational databases. Relational databases have survived more than 20 years and still doing well, even at large scale! There are extremely mature open source rdbms, requirement independent schemas, optimized queries for filtering, aggregation and list of data, great communities, acquired knowledge, default integration with programming frameworks and lots of tools developed.

RDBMS are great-for-all, unless…

Relational systems are super easy to work with, have great (free) tools for monitoring, backup, operations available, work well for most of the use cases, there is a lot of help (community, web resources, consulting) around and best of all.. you already know it well. Unless I have the following requirements I would use a single node relational database.

Super high availability

Relational database’s server process is a single point of failure, which means your system will go down, when the process crashes or taken down for scheduled or unscheduled maintainence. In short, prefer the boring system until a concrete requirement forces a different shape—and document that requirement so the next person does not re-litigate it from first principles.

If you are building a system which needs to have close to 100% availability, look into clustered relational databases or distributed databases which choose availability over consistency, eg. cassandra. In short, prefer the boring system until a concrete requirement forces a different shape—and document that requirement so the next person does not re-litigate it from first principles.

Flexible schema

One of relational databases’ great strength is its schema, data model and related concepts, which allow for schema modelling, without knowing the query patterns in advance, and works well. However, not all data can be effectively represented in relational data model. Even though there is some support for flexible schema datastructure, relational databases are efficitent on fixed schema which can confirm to normalization rules for a tradeoff between consistency and performance. Flexible schema do not work well with relational databases.

If you need (do you, really?) flexible schema, look at other nosql options. In short, prefer the boring system until a concrete requirement forces a different shape—and document that requirement so the next person does not re-litigate it from first principles. In short, prefer the boring system until a concrete requirement forces a different shape—and document that requirement so the next person does not re-litigate it from first principles.

Horizontal scaling

If you are looking to build a system that should scale horizontally as your data needs grow, a single-node relational database will not suffice forever. There is only so much room to grow, so much RAM and CPU to throw on a single machine. Sooner or later, you will hit that single server machine limit. At that point, you will have to either choose a NoSQL solution or a relational database system cluster.

Epilogue

NoSQL is no panacea and RDBMS are still the best choice for most of the applications. Unless you have strong need to not used a relational database, stick to it. In short, prefer the boring system until a concrete requirement forces a different shape—and document that requirement so the next person does not re-litigate it from first principles.