Skip to main content
José David Baena

Async Reliability Review

Make one async failure path easier to trust.

Start with one messaging or background-job flow that can repeat, stall, or recover unpredictably. The review maps the evidence, recovery boundary, and next actions your team owns.

The usual shape is roughly 8–10 hours over about two weeks. Other bounded design, pairing, and startup work remains below. This is independent personal work, not sponsored or endorsed by GitHub.

Describe one async flowInspect a synthetic handoffSee every collaboration mode

Start with a non-confidential outline. Do not include credentials, customer data, repository invitations, or confidential employer information. The link opens your email application; this website submits nothing.

Focus
Backend, platform, and distributed systems
Start
One messaging or background-job flow
Handoff
Failure map, priorities, and replay checklist
Access
Scoped non-production material by agreement
Ownership
Your team keeps review, release, and operations

Four ways to start

Start with the reliability review, or choose the decision that fits.

The Async Reliability Review is the flagship bounded offer. The other modes remain useful starting shapes, not an upsell ladder.

Working with a fund? Read the separate note for VC teams.

Inspect the public work

Evidence of the reasoning, not client case studies.

These resources show how I investigate systems, state assumptions, and turn failure boundaries into artifacts other engineers can inspect. They do not claim client outcomes for every collaboration mode.

Async Reliability Review

We inspect one messaging or background-job path and turn retry, replay, durability, migration, and ownership uncertainty into a bounded plan.

What we work through

  • Where attempts, effects, acknowledgements, and progress can disagree
  • Retry ownership, idempotency, ordering, and deadline assumptions
  • Replay evidence, dead-letter handling, and recovery boundaries
  • What the current metrics and runbooks can and cannot establish

What you leave with

  • A scope and assumptions map for the reviewed flow
  • Prioritized findings tied to evidence, impact, detection, and recovery
  • A recovery and replay checklist
  • Recommended next actions with clear ownership

Useful starting context

Redacted architecture or sequence diagrams; Retry, replay, dead-letter, and idempotency policies; Relevant dashboards, runbooks, or incident summaries; Selected code or configuration that defines the boundary.

Boundary: One existing flow. This is not implementation, incident response, a whole-platform audit, production access, certification, or on-call support.

Describe the flow by email

System Design

We turn product scenarios, workloads, constraints, and failure tolerance into a design that can be challenged before implementation locks it in.

What we work through

  • Requirements, constraints, workload assumptions, and unknowns
  • Service boundaries, state ownership, interfaces, and data flows
  • Alternatives across reliability, operability, cost, and team fit
  • Validation questions that should be answered before committing

What you leave with

  • A requirements and constraints brief
  • Architecture and sequence diagrams suited to the problem
  • Alternatives, trade-offs, and decision records
  • An implementation sequence with open risks and validation points

Useful starting context

The product scenarios the system must support; What exists today and who will build the result; Workload, reliability, budget, and timing constraints; Known dependencies and decisions already made.

Boundary: One agreed capability or system boundary. This is not architecture for the entire company, full product delivery, permanent ownership, or an untested scale guarantee.

Discuss a system design by email

Engineering Pairing

We work side by side on one bounded task: reproduce the behavior, inspect the relevant code or design, test hypotheses, and leave the reasoning with the team.

What we work through

  • A reproducible problem, focused design question, or implementation slice
  • Competing hypotheses and the evidence needed to distinguish them
  • Code and tests in an agreed, authorized workspace where appropriate
  • Knowledge transfer so the team can continue without me

What you leave with

  • Investigation and decision notes
  • Approaches tested and what they established
  • Agreed code or test changes where the scope permits
  • Unresolved questions, next steps, and named ownership

Useful starting context

A concise task or blocker; The engineers who will pair and the relevant stack; A reproduction, synthetic example, or narrow authorized workspace; What has already been tried at a non-confidential level.

Boundary: This is not unlimited staff augmentation, emergency support, ongoing availability, or release ownership. You retain credentials, review, merge, deployment, and operations.

Describe a pairing task by email

Startup Foundations

We define the smallest useful technical foundation for the next product milestone, avoiding both prototype chaos and a platform built years too early.

What we work through

  • The first useful user journey and the system boundaries behind it
  • Repository, service, data, configuration, and environment decisions
  • A practical baseline for tests, CI, releases, and observability
  • One bounded starter slice when implementation is explicitly agreed

What you leave with

  • A lean system map and decision record
  • An agreed starter slice with tests where hands-on work is in scope
  • A release, configuration, and observability checklist
  • A prioritized backlog with ownership for the next milestone

Useful starting context

What the product must do first; What exists today and who owns engineering; The next product or operational milestone; Team, time, budget, stack, and operational constraints.

Boundary: This is not the whole MVP, indefinite founding-engineer work, fractional CTO coverage, hiring, fundraising, compliance advice, or production operations.

Outline your startup's next step

Employment and teaching

Use a separate route when you are not looking for a client review.

I am open to conversations about relevant infrastructure and platform engineering opportunities, and about talks or workshops grounded in the public work on this site.

Infrastructure and platform roles

Share the role, problem space, and why the messaging, background-job, or developer-infrastructure work here appears relevant. This page does not claim a specific title, location preference, or start date.

Email about a relevant role

Talks and workshops to discuss

These are proposed topics backed by public articles and labs, not a claim about previous speaking engagements.

  • Retrying the unknown without repeating the effect

    A practical session on intent identity, crash-after-effect failures, reconciliation, retention, and the point where an automatic retry must stop.

    Inspect the source material

  • Kafka compatibility starts at the batch boundary

    A source-backed walkthrough of base offsets, offset deltas, append allocation, and the evidence needed before calling a protocol symptom data loss.

    Inspect the source material

  • Queue depth is not a recovery plan

    A workshop on turning arrival rate, service time, worker supply, cold starts, and downstream limits into a bounded drain-time decision.

    Inspect the source material
Discuss a talk or workshop

How we agree the work

Scope changes are decisions, not silent expansion.

  1. 01Start with a non-confidential outlineShare the problem, the current context, and the decision or milestone. Do not send credentials, customer data, repository invitations, or confidential employer information.
  2. 02Decide whether the shape fitsWe identify the right starting mode, the technical owner, the useful boundary, and what evidence is safe and relevant.
  3. 03Agree scope before workWe agree the question, handoff, working format, access model, fees, and timing. If the question changes, we revisit the scope.
  4. 04Leave ownership with the teamThe work ends with inspectable artifacts, unresolved risks, and named next steps rather than an open-ended dependency.

The boundary belongs in the handoff.

We agree access and responsibility before work begins. An NDA does not make otherwise inappropriate material safe to share, and collaboration does not transfer operational ownership.

Shared limits

  • No production credentials or unrestricted repository access by default
  • No customer data or confidential employer material through ordinary email
  • No emergency support, on-call obligation, certification, or guaranteed outcome
  • No implied sponsorship or endorsement by GitHub

Your team retains

  • Credentials and access approval
  • Review, merge, deployment, and rollback
  • Production operations and incident command
  • Business, legal, security, and compliance decisions

A separate collaboration lane

For VC teams

I have collaborated with VCs before, mostly in a recommendation role. I am open to discussing scouting and recommendation work under an agreed remit. Scope, fit, conflicts, and timing need to be agreed before any work.

Discuss VC collaboration

Possible shape

  • Recommendation-based collaboration around a clearly defined focus
  • Scouting or sourcing conversations with explicit scope and conflicts
  • A bounded recommendation process with clear decision ownership

What this does not claim

  • My previous work is described as recommendation-based, not as a formal scout title or an investment outcome.
  • This is not investment advice, fundraising representation, recruiting, or an implied affiliation with a fund.
  • Start with a non-confidential outline; do not send confidential decks, founder identities, or deal material without an agreed process.

Start here

Tell me what you are trying to build or decide.

We can decide which collaboration shape fits after the first non-confidential outline. Fees, timing, access, and the exact handoff are agreed before work begins. Start with one decision, task, flow, or milestone and name who will own the result.

Email about a collaborationjosedab@gmail.com

Clicking an email link opens your email application. It does not book time, submit a form, or confirm that an engagement exists.