Pepy

A derived copy drifts whenever the source schema or the conversion logic changes without the other being updated. A column added to a model does not reach search, or a converted value is indexed in the wrong shape, and the first sign of it is a filter returning the wrong set. Neither store reports an error, because from each side the data it holds is valid.

Each model declares which of its columns matter to search in an explicit field list, and has a matching pair of conversion functions between the database shape and the search shape. Adding a column is therefore three coordinated changes, not one: the migration, the field list, and both converters. I built and maintained that across the models I worked on.

The mapping between the two stores was declared in code next to the model. That gave reviewers an explicit checklist for a schema change: the migration, field list, and converters. It made omissions easier to identify, without guaranteeing that every omission would be caught in review.

A derived copy needs a rebuild path, because it will eventually be wrong. Rebuilding by emptying and repopulating the index that search is currently reading from would take search down for the length of the reindex.

I wrote migrations and seeders that reindex tables into Elasticsearch, either one model at a time or across the board, so a rebuild is one repeatable command. The build script checks whether an index alias exists for a given model and creates it if not. With the alias in place, a rebuild indexes into a new index and repoints the alias to it, so the live index is never truncated.

Reindexing became a repeatable operation without requiring the live search index to be emptied first. I confirmed the production Elasticsearch and Node versions with DevOps before relying on any of it, and had them verify the affected index in production after a reindex. That check alone does not establish how writes arriving during a rebuild reach the new index.

Pepy needed to pull task data from the tools teams already used, so the Trello, GitLab, and Google connections had to be built, not taken from an SDK. Most of the work was not the code-for-token exchange but the failure cases around it and the multi-tenant setup.

I built the flows and the recovery around them. When a stored token has been invalidated upstream, it has to be removed along with the saved board and list settings. Otherwise the user is left with a dead connection they cannot re-establish. Board and list names are stored alongside their identifiers so the settings screen can show readable names. Trello will not return a user's email unless the correct scope was requested at authorization time. Adding that scope later means asking every connected user to reauthorize, so it had to be settled before rollout. On the Google side, an unverified tenant needed its redirect URI rewritten to the registration subdomain, since one registered callback does not cover every tenant.

Partway through, ownership of the Trello token moved to the frontend, so I rebuilt that connection against the new arrangement and closed the original merge request instead of trying to salvage it.

A user can disconnect and reconnect without support intervention, tenants that are not yet verified can still complete a Google sign-in, and the required Trello scope was established before rollout, avoiding a later forced reauthorization of connected users. I ran the disconnect and reconnect path end to end instead of only checking that the token row had been removed. QA and I then both signed in from a tenant whose subdomain was not registered as a Google callback, and the rewritten redirect URI carried the sign-in through.