Engineering at The Drivers Coop

May 30 · 9min

A political journey

In 2021, my political intrigue starting moving leftward. I’d always labelled myself a left-liberal or social democrat (“Europe has free healthcare and education, isn’t that rad?”).

After reading Lizzie O’Shea’s Future Histories, I felt like I saw the truest value of technology. It wasn’t too enable billionaires to colonize Mars or aid in other fun frivolities. It was to emancipate; to help people; to facilitate alternative ways of economic organization that prioritize peoples’ needs over profit and unsustainable growth, and prevent inequality, monopolization, and domination.

It’s not that we need to abolish markets — there’s an interesting case for that, but it’s an entirely different discussion. On the contrary, it’s about reconfiguring and refactoring our existing modes of organization to limit the worst pathologies of our economic system.

I was happy to read about the rise of worker cooperatives in New York City. Former Uber and Lyft drivers were organizing themselves under The Drivers Cooperative, a crowd-funded company free from all the pressures that come with venture capital, and building a healthy, sustainable, democratic system of governance that would allow drivers to work on their own terms and to finally shift away from an industry that had never really had their backs.

In Fall 2021, I heard about the story of Kenny Chow — a cab driver who was drowning in $750,000 debt and eventually died by suicide — and the ensuing hunger strikes. The industry has been predatory and immiserating for a while. Uber coming along didn’t help things. And these depredations weren’t simply happening in New York, but elsewhere around the globe:

After listening to a podcast featuring the CTO of The Drivers Cooperative, I was hooked and knew I wanted to support the platform cooperative movement.

After volunteering for a few weeks, I knew I had to jump in full-time to really accelerate my learning curve — (I had either never, or only marginally, used Hasura, Typescript, and Postgres functions).

I left my role at and took a 50% pay cut to work as a contractor.


In the end, I made some cool contributions:

  • A real-time UI: built with React, that allowed dispatchers to manage and visualize their fleet, and included a nifty Google Map which provided real-time trip locations and updates;
  • Query performance: a 15s -> 1s SQL query performance improvement using indexes, event sourcing, and denormalization (wider tables, fewer JOINS);
  • Dispatch server: an open-source, traffic-aware dispatch server to identify passengers nearest to a driver; written in Go and, ironically, powered by Uber’s own geospatial indexing library, H3. (Uber has made some insane contributions to the world of engineering, but that doesn’t mean their economic model shouldn’t be scrutinized, condemned, and combatted. 😎)

Event sourcing

Event sourcing was one of those patterns I had heard about for a long time but never actually used in production.

At TDC, it served us well both in terms of performance and in our ability to grok the actions taken by users.

For an explanation, imagine you have a job (trip) table. A job has an ID, a status (e.g., pending, in progress, complete), and an associated driver.

In the simplest CRUD applications, this state table is all you’d have. Mutations would happen directly to an entity, and there would be no trail of mutations occurred.

Event sourcing provides that trail and lets you reconstruct entity state based on a log of events (e.g., “job_log”). For simplicity, we decided log records could just have a jsonb payload. This kept the schema small and homogenous across different types of tables (e.g., job_log, driver_log, vehicle_log — they all had that familiar jsonb column).

From the perspective of the UI client, instead of doing CRUD on the job table, they would shift to doing change is you do inserts on the log table. The “event type” field is useful for distinguishing creations, updates, and deletions. Postgres triggers are used to update the state table (e.g., job) in tandem with the log table (e.g., job_log).

comment on twitter